Re: [Talk-de] I Like OpenStreetMap
Habe auch mal dem Daumen gesenkt für eine Industrie-/Gewerbefläche fläche wo ein Hersteller sitzt. ;) Wenn die Frage danach was man mit dem Daumen hoch/runter eigentlich konkret bewertet werden soll bewusst offen gelassen wurde ist das natürlich ein interessants Experiment. (auch wenn man wohl nie erfahren wird was der User denn dann auch gemeint hat). Also wenn es primär auf die Datenqualität abzielt sollte die Fragestellung doch schon wenigstens konkreter sein um einen brauchbaren Nutzen für OSM zu haben. also statt -/+ für diesen Kartenabschnitt? dann +/- Datenqualität in diesem Kartenabschnitt? Unabhjängig davon ob man ggf. noch weiter auf die ein oder andere Weise aufdröselt, z.B. ein Textfeld wo man eben was reinschreiben kann oder direkt mit Openstreetbugs verknüpft. Am 01.09.2012 23:13, schrieb Holger: Ich habe grad den Daumen bei einer Stadt gesenkt, die ich nicht mag. Bin mal gespannt, wie ihr die Lebensqualität dort jetzt verbessern wollt. Oder um es mit anderen Worten zu sagen: Ich verbinde Daumen hoch/runter mit dem auf der Karte dargestellten Ort, nicht mit den Daten. Ich bin daher etwas skeptisch, dass sich mit den gesammelten hoch/runter Daten etwas anfangen lässt. Holger Am 01.09.2012 18:55, schrieb malenki: Pascal Neis schrieb: der Eine oder Andere von Euch hat vlt. Frederik's Idee zu einer Qualitaetskontrolle stochastisch auf der Mailling-Liste hier gesehen [1]. Seine Idee war grob zusammengefasst einen OSM Kartenausschnitt durch zwei Buttons ala Facebook über Dauem hoch oder runter zu bewerten. Evtl. kommen dabei nicht verlässliche Daten heraus, aber es dürften zumindest Indikatoren oder Trends in den OSM Kartendaten zu erkennen sein. Zwei Sachen bleiben zu hoffen: * Dass es genügend User gibt, die die Qualität negativ bewerteter Regionen verbessern (können). * Dass unbedarfte Besucher nicht disliken, weil ihnen der Stil beziehungsweise die Fülle an Daten missfällt. Ansonsten Danke für das Tool - mal sehen was daraus wird. Thomas, die erste Gegend¹ disliked habend ¹ http://openstreetmap.de/karte.html?zoom=14lat=44.10077lon=22.6976layers=B000TT ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Start des deutschen WikiProjekts Cleanup
Am 19.03.2012 10:20, schrieb Wolfgang: Dazu sollte auch die Struktur des Wiki überdacht werden. Ein Anfänger, der nicht in diesen Strukturen zuhause ist, hat erst mal ein Problem, überhaupt Informationen zu finden. Der nahezu einzige Weg dazu ist die Suche nach Stichwörtern. Wenn man aus der text- (Buch-)gebundenen Welt kommt, ist man es gewohnt, Inhaltsverzeichnissen folgen zu können. Insofern sollte zumindest für den Einsteiger ein Inhaltsverzeichnis wie eine Art Gliederung angelegt werden. (Nicht allumfassend, das geht gar nicht, sondern das Wichtigste für den Anfang). Es gibt zwar den Map Overview, aber die darin enthaltenen Links zeigen auf Verzeichnisse, deren Links dann in Relationen münden - für einen Anfänger absolut abschreckend. Was noch gut (aber nicht aktuell) einführend erklärt wird, ist die Auswertung der Daten. Was fehlt, ist so etwas wie erste Schritte, Tags finden, im Wiki suchen, Struktur des Wiki, wichtige tags. Das ganze möglichst kurz und knapp, nur das Wichtigste mit der Möglichkeit, nach weiteren Infos zu suchen. Die meisten Anfänger wollen nicht von Informationen erschlagen werden, aber auch nicht nach Infos suchen müssen. Im Moment sind eher das Aufnehmen der Daten mit dem GPS und die Auswertung der fertigen Daten erklärt. Es fehlt ein aktuelles Kartieren für Anfänger. Erscheint mir immer noch als eine der wichtigsten Anlaufstellen beim mappen selbst: http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A bzw: http://wiki.openstreetmap.org/wiki/DE:Map_Features Wenn diese Liste(n) schon schneller zu finden wäre, also so wie auf der englischen wiki Hauptseite, dann auch auf der deutschen Hauptseite, dann wäre denke ich schon viel gewonnen. Kein Einsteiger scrollt in dem Textberg so weit runter bzw. erwartet vermutlich überhaupt nicht hinter Eigenschaften der Kartenelemente so eine Liste... http://wiki.openstreetmap.org/wiki/DE:Main_Page ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] geplantes Pumpseicherwerk
Netter Tippfehler im Betreff... ;) Am 24.02.2012 01:21, schrieb Garry: Die Variationsmöglichkeiten sind sehr begrenzt. Topografie, notwendige Höhendifferenz, Speicherkapazität etc. setzen enge Grenzen wo und wie das Pumpspeicherkraftwerk realisiert werden kann. Dazu ergibt sich aus dem geplanten Atomausstieg ein gewisser Zeitdruck das Projekt zu realisieren. Bei uns vor der Haustür ist auch ein Pumpspeicherkraftwerk geplant und es gibt auch eine grobe Zeichnung (Idee) wo das hinkommen soll. Allerdings bin ich der Meinung das man das erst eintragen sollte nachdem es einen Planfeststellungsbeschluss, Baubewilligung etc. gibt, also klar ist so wird es gebaut und nicht irgendwelchen unfertigen fiktiven Ideen/Varianten eines Unternehmen xy oder des Staates eingetragen werden. Gerade in so einer frühe Phase wo evtl. noch mehrere Varianten zur Diskussion stehen die dann womöglich alle in OSM eingetragen werden sollen. Beim besten willen nicht, dann trägt demnächst jeder seine Wünsche und Ideen aufs Geratewohl ein... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing-Luftbilder
Am 08.02.2012 21:58, schrieb Christian H. Bruhn: Hallo! Wenn es um Luftbilder geht, werden immer die zukünftigen Bing-Bilder erwähnt. Für mich erzeugten die Infos aus den Postings den Eindruck, es gäbe Mitte des Jahres flächendeckend (!) hochauflösende (!) und aktuelle (!) Luftbilder für ganz (!) Deutschland. Bei Bing/Microsoft selbst habe ich immer nur etwas von Testgebieten gelesen. Was ist also an der Sache dran? Christian P.S. Mir ist aufgefallen das Google die neuen Luftbilder von den Vermessungsämtern bisher nur in Gebieten einsetzt, wo sie vorher noch keine anderen guten Bilder hatten. Daher fehlt manches Neubaugebiet bei Google, obwohl schon in den amtlichen Luftbildern drin ist. Auflösung 30cm / Juni 2012: http://forum.openstreetmap.org/viewtopic.php?id=11373 http://www.bing.com/community/site_blogs/b/maps/archive/2011/06/27/bing-maps-unveils-exclusive-high-res-imagery-with-global-ortho-project.aspx ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nord-Stream-Pipeline
Am 06.02.2012 16:25, schrieb Johann H. Addicks: wird und in weiten Teilen noch gut sichbar ist. Ein gewaltiges Bauwerk das sicherlich in OSM rein sollte, auch wenn in einigen Jahren nicht mehr sichtbar ist. Aber wir mappen ja auch Stromleitungen .-) Ich vermute, dass diese Pipeline es auch in die Liste der kritischen Infrastrukturen kommt. Wenn wir alles mappen, was da auf der NIPP- und CIKR-Listen steht, dann klopft vermutlich bald die nächste Behörde.. siehe auch http://www.heise.de/tp/artikel/33/33788/1.html Wäre doch schön wenn sie dann die Trasse im Vorfeld verpixeln, dann ist das mappen auch gleich viel einfacher. ;) Das sollten wir bei solchen Sachen dann immer so machen. Am besten fangen wir auch gleich mit CEPS/NEPS an um eine entsprechende Reaktion auszulösen: http://de.wikipedia.org/wiki/Central_Europe_Pipeline_System ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport nach OpenStreetMap
Am 03.02.2012 22:17, schrieb Frederik Ramm: Hi, On Fri, 03 Feb 2012 19:29:07 +0100 Mnorthc...@gmx.de wrote: Ist man denn heute immer noch so pingelig bei solchen Importen? Sprich Information x (ohne Geokordinate) aus legaler Quelle wurde anhand google Luftbild (von einem einzigen User) jeweils einer Position zugeordnet. Dadurch hat nach unserer Lesart Google einen Anteil an den Rechten der gewonnenen Information. Mittlerweile gibt es allerdings die Luftbilder von Bing mit denen man die Daten dann sozusagen remappen kann - natürlich nur wenn das dann auch aus den Bing Luftbildern hervorgeht. Wo wäre da dann der konkrete Stein des Anstoßes bzw. das zu lösende Problem? Wenn der Benutzer behauptet, die Daten anhand von Bing-Bildern positioniert zu haben, und niemand ihm nachweisen kann, dass sie von Google kommen, ist die Sache ok. Wenn der Benutzer aber sagt: Ich habe das hier anhand von Google positioniert, aber ich *haette* es genauso gut anhand von Bing positionieren *koennen*, dann ist die Lage unveraendert - Google hat einen Anteil an den Rechten und die Daten sind nicht nutzbar. Das klingt ein bisschen absurd, aber leider gibt es Urheberrecht nicht fuer etwas, was man haette machen koennen ;) Beim Remappen ist es aehnlich - ein Nichtzustimmer hat eine Strasse abdigitalisiert, und ich koennte sie jetzt 100% genau so abdigitalisieren - aber es reicht nicht, dass ich *koennte*, ich muss es tatsaechlich *tun*. In dem Moment wo ich bestätige das die Daten (x,y Koordinate) entsprechend des Bing Luftbildes so stimmt ist es aber doch so das die Quelle für die Position nicht mehr Google ist sondern Bing. Das anschauen der Poi habe ich ja entsprechend der Nutzungsbedingungen von google gemacht. Die eigentliche Quelle für OSM ist dann allerdings Bing. Poi Sammlungen aufgrund google earth werden doch massenhaft im web verteilt, ist das nicht legal ? -- Nicht ganz ernst gemeint: Oder bedeutet es das mich nun die MiB aufsuchen und Blitzdingsen [1] wenn sich zuvor die Information aus den POI (aus google Luftbild) in meine Hirnwindungen verirrt hat, so dass ich diese Information aus meinem Hirn nicht mehr abrufen kann wenn ich mir die Bing Luftbilder anschaue um ebenfalls diesen Poi zu setzen? Das heißt google hat nun Teile meines Gehirns in seinem Besitz bis ich geblitzdingst werde oder mich Demenz/alzheimer etc. es vergessen lässt? -- [1] Handelsüblicher Neuralisator. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenimport nach OpenStreetMap
Am 26.01.2012 17:47, schrieb Frederik Ramm: On 01/26/2012 03:42 PM, Chris wrote: An dieser Stelle aber der Hinweis: Falls Deine POIs von Nutzern mit Hilfe einer darunterliegenden Google-Karte eingezeichnet wurden (so a la Du weisst, wo ein AED steht? Zoome einfach in dieser Google-Karte an die richtige Stelle und klicke drauf...), so halten wir die Daten in der Regel fuer ein von Google abgeleitetes Werk, an dem Du bzw. der Erfasser nicht die alleinigen Rechte hat und das deswegen auch nicht unter die OSM-Lizenz gestellt werden kann. Dem ist so. Also hat sich der Import schon erledigt. Wir hatten eine aehnliche Situation vor einigen Jahren mit dem Projekt OpenAddresses. Die hatten auch auf Basis von Google (Luftbild in dem Fall) erfasst und fanden selber nichts dabei; OSM war dann pingeliger und hat gesagt nee, Eure Daten wollen wir nicht. Das war ein bisschen eine bloede Situation damals, und ich persoenlich fand das etwas uebertrieben, aber OSM wollte da halt 100% clean sein. Mittlerweile ist die Situation mit OA ja anders, man editiert praktisch auf der OA-Plattform direkt OSM-Daten. Ist man denn heute immer noch so pingelig bei solchen Importen? Sprich Information x (ohne Geokordinate) aus legaler Quelle wurde anhand google Luftbild (von einem einzigen User) jeweils einer Position zugeordnet. Mittlerweile gibt es allerdings die Luftbilder von Bing mit denen man die Daten dann sozusagen remappen kann - natürlich nur wenn das dann auch aus den Bing Luftbildern hervorgeht. Wo wäre da dann der konkrete Stein des Anstoßes bzw. das zu lösende Problem? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
Also hier wird zumindest bei Bing verschleiert ohne das die Fläche als military markiert ist: http://binged.it/zjpsHZ http://maps.google.de/maps?q=ruppertsweilerhl=dell=49.198612,7.681498spn=0.002801,0.008256sll=51.151786,10.415039sspn=22.086482,67.631836hnear=Ruppertsweiler,+Rheinland-Pfalzt=hz=18 http://www.openstreetmap.org/?lat=49.198959lon=7.681116zoom=18layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tools zum Remappen NACH dem Lizenzwechsel?
Am 15.12.2011 17:57, schrieb Bernd Wurst: Schwierig finde ich den Punkt (was ich absolut erwarte), wie man mit Ablehnern umgeht, die später doch noch zustimmen möchten. Das betrifft ja nicht nur Ablehner sondern auch Unentschiedene die erst nach der Umstellung zustimmen. Kann ja durchaus 1 Jahr später oder länger nach Umstellung sein. Ein automatisierter Import macht dann ja keinen Sinn mehr. Sehr sinnvoll wäre es wenn man dann die Daten der Nachzügler gezielt in JOSM sichtbar (wie auch immer) machen könnte um sie manuell möglichst einfach wieder einpflegen zu können. Es handelt sich dann ja um einen legalen Vorgang. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Am 13.12.2011 09:43, schrieb Frederik Ramm: Unmut bei den einen - Freude bei den anderen. Damals haette man auch sagen koennen: Nee, Luftbilder wollen wir nicht, das zerstoert unsere Outdoor-Kultur. Man muss also schon immer genau schauen, um was fuer einen Unmut es geht, und welche Kultur dieser Unmut viellicht bedroht; nicht jeder Unmut muss bekaemft und nicht jede - vermutete - Kultur erhalten werden. Da reicht es nicht, darauf zu hoffen, dass schon genügend andere nachrücken werden. Denn auch wenn sie das tun: die Kultur wäre zerstört. Ich meine das die Qualität von OSM eben nur durch outdoor-Kultur aufrecht erhalten werden kann. Entsprechend hat jeder User seinen Aktionsradius den er hegt und pflegt und das funzt wenn ich mir meine Nachbarn so ansehe recht passabel. Auch wenn die Produktivität so zwangsweise ein wenig mit der Zeit nachlässt da die Wege die man zurückzulegen hat weiter werden. Man kann eben vieles nicht auf dem Sat.-Bildern erkennen. Den Nutzen der Sat.-Bilder sehe ich in erster Linie darin das man bequem und auch gut die Flächennutzung mappen kann (Wald, Acker, Wiese, etc.). Für Wege ist es mir eher eine zusätzliche Referenz um den GPS Log abzugleichen (Genauigkeit, Kurvenverlauf etc.) Beim neu mappen von Wegen über Sat.-Bilder entsteht immer der fade Beigeschmack das es nicht optimal ist (tracktype usw.) und ich früher oder später sowieso (immer mal wieder) vor Ort vorbei muss um mir anzuschauen was Sache ist. Wege in Wäldern per Satbilder mappen zu wollen kann man sowieso nahezu vergessen. Jeder Import braucht einen Mapper mit Ortskenntnis. Fuer mich ist bei importierten Hausumrissen eine Grenze ueberschritten - ich sehe da unsere Selbermach-Kultur in Gefahr. Ich glaube, dass viele unserer Erfolge darauf basieren, das wir selber machen und nicht warten, dass/bis uns gegeben wird. Ich wuerde mir auch wuenschen, dass wir, wenn wir Haeuser wollen, diese selbst von aktuellen Luftbildern abdigitalisieren - nicht zuletzt, weil ich den Wert von OSM auch darin sehe, eine zweite Meinung zu sein inmitten des Wusts von Geodaten, die alle aus der gleichen Quelle abgeschrieben sind. Bei dem Punkt Häuser bin ich der Meinung das es mit der bisher überwiegend vorliegenden Luftbildauflösung keinen Sinn macht da was abzumalen. Es gibt immer anderes zu tun was man machen kann bevor ich mich aus absoluter Langeweile damit beschäftige und dann wenn eine höhere Auflösung oder gar die millimetergenauen Daten (eingemessene Gebäude) vom Katasteramt vorliegen ich feststellen muss es war sowieso im weitesten Sinn für die Katz. Genausowenig habe ich Wälder gemappt bevor die Bilder von Bing verfügbar waren. Die yahoo Bilder vorher waren so grob da hat man mal 100m daneben gelegen. Waldgrenzen mit dem GPS Logger abzulaufen habe ich mal testweise gemacht und für nicht effizient (ziemlich ätzend) und auch nicht im Ergebnis gut befunden verglichen mit Satbildern. Dahabei ch mich erstmal mit anderem beschäftigt. Mit dem GPS Logger bei +5m Genauigkeit Gebäude in die OSM bringen zu wollen halte ich ebenso für eine Verzweiflungstat aus Langeweile. ;) Die zweite Meinung von OSM sehe ich in der Ortskenntnis/Qualitätssicherung eine Mappers vor Ort. Egal worin die Ursprungsquelle der Daten mal bestanden hat. Wenn es Hilfsmittel wie Sat.-Bilder oder Importe gibt die den reinen Erfassungsvorgang dem Mapper erleichtern und er sich mehr auf die Qualitätssicherung im weitesten Sinn beschränken kann ist das nur sinnvoll. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Heise: Google Maps wird kostenpflichtig
http://www.spiegel.de/netzwelt/netzpolitik/0,1518,794935,00.html Von selber rendern steht da halt mal wieder nichts. Mehr so nach dem Motto, google raus und dann machts dann halt OSM (und deren Server - bis er aus dem letzten Loch pfeift...). Bin ja mal gespannt wie das dann mit Seiten wie gpsies.com künftig läuft. Am 29.10.2011 12:48, schrieb Philip Gillißen: Ich habe gerade eine für OSM positive Erfahrung mit dieser Nachrichtenmeldung gemacht. Ich habe auf Google+ diese Nachricht verbreitet und schon kam im Ansatz eine ähnliche Diskussion in Gange wie hier, vor allem die Bedenken, dass OSM ja nicht kostenlos Tiles millionenfach ausliefern kann. Aber... als ich erwähnte, dass man auf einem eigenen Server selber rendern lassen kann, hat ein Programmierer zugegeben, dass er das noch nicht wusste und er das eventuell in seinem neuen Projekt nutzen kann. Der Kontakt ist hergestellt und jetzt heißt es abwarten :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] R: Modellflügzeuge und Modellwagen ?
Wie sieht dein Vorschlag konkret aus ? Verstehe halt immer noch nicht so ganz welchen Unterschied es machen soll ob ich die Fläche nun unbedingt mit runway oder dem bisherigen Schema benenne. Gruß Am 26.10.2011 17:47, schrieb Garry: Am 26.10.2011 10:08, schrieb M: Am 25.10.2011 22:47, schrieb Garry: [...] Es geht nicht um den Ersatz der amtlichen Karten aber eine unabhänge zusätzliche Informationsquelle kann nicht schaden und so vielleicht den nächsten Todesfall wegen eines all zu sorglos überfliegen eines Modellflugplatzes verhindern. [...] Es geht mir nicht um aerodrome sondern um runway als eindeutiges Merkmal dass hier mit aufsteigenden Luftfahrzeugen zu rechnen ist, gleich welcher Grössenordnung und bemannt oder unbemannt. Dafür sind die Zusatztags da und ein erster Hinweis auf die Grössenordnung ist aus der Länge der runway gegeben. [...] Kann es sein das du übersiehst das in komplett Deutschland, unabhängig von Modellflugplätzen und Geländen mit aufsteigenden Modellflugzeugen zu rechnen ist? (explizit gesperrte Bereiche mal aussen vorgelassen).Modellflugzeuge darfst du von jedem Feldweg oder Wiese oder was auch immer aus starten. Auf jedem Acker kannst Du Kraftfahrzeuge (Traktoren, Mähdrescher,..) antreffen, die Gefahr von einem KFZ überfahren zu werden ist bei überqueren einer Autobahn aber ungleich höher als beim überqueren eines Ackers... Was ausserhalb von Modellflugplätzen(oder grösser) rumfliegt gehört meist zu einer Gewichts/Grössenkategorie die ehr weniger eine Gefahr für die bemannte Luftfahrt darstellt. Wie gesagt, wie das Kind letzten Endes heißt ist doch egal wenn jeder weis welches Kind damit gemeint ist. Irgendwann drückt man im editor doch sowieso nur noch auf einen Button und welchen Namen der Schlüssel/wert am Ende in der Datenbank hat ist dann egal... interessiert dann nur noch denjenigen der eine Karte daraus erstellt. und da wüsste (oder verstehe) ich nicht was es nun ändert das sport=model_aerodrome in etwas anderes umzubenennen (?). Oder reden wir aneinander vorbei? Mir geht es insbesondere um die durchgängige Nutzung von runway als ein Stück Weg dass überwiegend dem Übergang von Luftfahrzeugen zwischen Luft und Erde vorbehalten ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] R: Modellflügzeuge und Modellwagen ?
Am 25.10.2011 22:47, schrieb Garry: [...] Es geht nicht um den Ersatz der amtlichen Karten aber eine unabhänge zusätzliche Informationsquelle kann nicht schaden und so vielleicht den nächsten Todesfall wegen eines all zu sorglos überfliegen eines Modellflugplatzes verhindern. [...] Es geht mir nicht um aerodrome sondern um runway als eindeutiges Merkmal dass hier mit aufsteigenden Luftfahrzeugen zu rechnen ist, gleich welcher Grössenordnung und bemannt oder unbemannt. Dafür sind die Zusatztags da und ein erster Hinweis auf die Grössenordnung ist aus der Länge der runway gegeben. [...] Kann es sein das du übersiehst das in komplett Deutschland, unabhängig von Modellflugplätzen und Geländen mit aufsteigenden Modellflugzeugen zu rechnen ist? (explizit gesperrte Bereiche mal aussen vorgelassen). Modellflugzeuge darfst du von jedem Feldweg oder Wiese oder was auch immer aus starten. Wie gesagt, wie das Kind letzten Endes heißt ist doch egal wenn jeder weis welches Kind damit gemeint ist. Irgendwann drückt man im editor doch sowieso nur noch auf einen Button und welchen Namen der Schlüssel/wert am Ende in der Datenbank hat ist dann egal... interessiert dann nur noch denjenigen der eine Karte daraus erstellt. und da wüsste (oder verstehe) ich nicht was es nun ändert das sport=model_aerodrome in etwas anderes umzubenennen (?). Oder reden wir aneinander vorbei? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] R: Modellflügzeuge und Modellwagen ?
Am 20.10.2011 23:56, schrieb Garry: Am 20.10.2011 12:58, schrieb Alech OSM: Ich nicht ! ^_^ Köntte passend sein, aber auf einem Modellflugplatz finden sich zumindest eine Art von Tower und ein Gebäude , wo die Modellflugzeuge eventuell repariert werden können. Was verwendet mann denn für die Landebahn , oder für einen RC-Modellwagenstrecke ? Eine Landebahn ist eine Landebahn. Die Zusatztags erlauben genau festzulegen was dort starten und landen darf - von der kurzgemähten Graspiste für Modellflugzeuge bis zum A380... . Ein Tower auf einem Modellflugplatz? Wäre mir neu. Das es ein paar Tische zum Modell vorbereiten oder auch mal ein Clubhaus hat ist aber üblich aber nicht die Regel. Bei Hangfluggeländen gibt es in fast allen Fällen keine Landebahn oder irgendwas das das Gelände als solches kennzeichnet. Vergleichbar mit tourism=viepoint. Ob Modellflug in die Kategorie Leisure oder Sport gehört in OSM ist doch unwichtig. Hauptsache das Kind hat überhaupt einen Namen. Möchte aber dennoch darauf hinweisen das es sich um Modellflug_sport_ handelt. Der DAeC ist beispielsweise Mitglied des DOSB (Deutscher Olympischen Sportbund). In sofern ist Sport meiner Meinung nach richtiger. ;) Welchen Tag würdet ihr vorschlagen für die Kennzeichnung als Hangfluggelände ? Vorschlag: model_aerodrome:slope_soaring= yes/no bei Gelegenheit kann man dan nauch mal in howtotag etc. einen link setzen oder ist der nur für 'Approved' ? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Modellflügzeuge und Modellwagen ?
Am 19.10.2011 17:24, schrieb fschmidt: Am 19.10.2011 17:01, schrieb Steffen Heinz: Allerdings falle auch Modellflugplätze unter das Flugverkehrsrecht - sie werden ganz ähnlich wie Klein) Flughäfen behandelt müssen also umflogen werden Bist du sicher? Ich habe in meiner ICAO-Karte keinen einzigen Modellflugplatz gefunden. Und was nicht in der ICAO-Karte ist, existiert für mich als Flieger nicht. Wie soll ich es da umfliegen? Frage ging zwar nicht an mich. Aber eine Pflicht Modellflugplätze zum umfliegen gibt es nicht. Natürlich sind die Nicht auf ICAO-Karten. Der Modellflieger ist zu jedem Zeitpunkt Ausweichpflichtig, nicht der Manntragende. Zudem muss man mal die Bezeichnung Modellflugplatz und Modellffluggelände trennen. Es gibt Gelände die haben eine Aufstiegsgenehmigung durch das jeweilige Luftamt (Ländersache) bekommen nach dem es der Verein oder eine Einzelperson beantragte. Häufig deshalb um Modelle mit mehr als 5kg (idR bis 25kg) oder auch Großflugmodelle mit bis zu 150kg fliegen zu dürfen. Es kann auch sein das aus Lärmschutzgründen (weniger als 1,5km zum nächsten Ort) normalerweise nicht mit Kolbenmotor oder Turbine geflogen werden darf und daher eine Aufstiegsgenehmigung ausgestellt wurde (schärfere Begrenzung). Oder oder... Wie auch immer, es gibt auch Modellflug und Vereinsgelände die keine explizite Aufstiegsgenehmigung vom Luftamt haben (möchten) weil dort Modellflug einfach nur nach den allgemein gültigem Gesetz stattfindet. Dort gilt dann das gleiche recht als würde man auf jeder x beliebigen Wiese stehen. Also deswegen bitte auf keinen Fall Flugplätze und Modellfluggelände oder Modellflugplätze in einen Topf werfen. Der aktuelle Vorschlag sieht so aus: http://wiki.openstreetmap.org/wiki/Proposed_features/Model_Aerodrome Was man noch ergänzen könnte wäre ein Tag der das Gelände ggf. als reines Hangfluggelände ausweist. Siehe z.B. den Hangflugführer: http://wiki.rc-network.de/Kategorie:Hangflug So lässt sich das evtl. noch besser trennen. Leider war bisher wenig Beteiligung in der Sache Tagging Modellflug. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe bei einer Insel - Ergänzung
Am 22. August 2011 16:18 schrieb Jan Tappenbeck o...@tappenbeck.net: habe da noch einen Nachtrag - hatte mir nur eine Fläche aus einem Rechteck als Sandbox mal erzeugt in der Nähe vom KIRR und dieselben Tags wie vom o.g. [1] zugewiesen. Hier wurde nur der Name und auch nicht die Freistellung gerendert. (zwischenzeitlich wieder gelöscht!). Ich finde es mehr als merkwürdig. Hallo Jan, wie schon im parallelen Thread erklärt: die Küstenlinien (natural=coastline) werden nicht wie die übrige Karte sondern in einem separaten Prozess in Mapnik behandelt (shapefiles). Ist Dein Problem in T@H auch vorhanden? Wenn nicht, dann einfach mal einen Monat oder so abwarten, dann sollten die Änderungen in Mapnik auch angekommen sein. Wie ebenfalls bereits erwähnt, ist bei den Coastlines die Richtung des Ways wichtig: links liegt das Land, rechts das Meer. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 22. August 2011 08:41 schrieb Christian Müller cmu...@gmx.de: Am 22.08.2011 07:10, schrieb Joerg Fischer: Ganz genau hinschauen muss er eher, wenn die Fläche /nicht/ an den Weg gepappt ist - denn dann ist es fast Zufall bei entsprechender Zoomstufe, ob der node in den Weg der Fläche eingefügt wird, oder in den Weg. Maus mit Rad hast Du? Bei den Zoomstufen, bei denen es Zufall ist, wo man den Node einfügt, sollte man ans Editieren nicht mal denken. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 22. August 2011 11:54 schrieb Dimitri Junker o...@dimitri-junker.de: Aber nenn mir doch mal ein konkretes Bsp wo die getrennten Linien Sinn machen, also folgende Bedingungen erfüllt sind: ... Gegenfrage: wieso sollte man es beim Rendern dem Zufall (der Straßenbreitendarstellung) überlassen, wo eine Fläche aufhört? Was soll daran besser sein, wenn der Park auf dem Gehweg oder im Rinnstein endet anstatt dort, wo er tatsächlich zu Ende ist? Gerade beim Rendern von großen Zoomstufen ist es doch erwüscht, auch Details erkennen zu können, eine Vergrößerung der Flächen potentiell bis zur Straßenmitte (wenn man nur ein Haarlinie rendert oder die Straße ganz weglässt) schadet mehr als sie vermeintlich nützt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 22. August 2011 11:54 schrieb Dimitri Junker o...@dimitri-junker.de: sofern es ausser der Nähe eine Beziehung gibt. entweder die Fläche grenzt an die Straße, dann ist das eine Beziehung, oder sie grenzt nicht dran, dann ist aber klar, daß sie eine getrennte Linie braucht. in der überwiegenden Zahl der tatsächlichen Fälle, wo ich in OSM Flächen gefunden habe, die bis zur Straßenmitte gezogen waren, grenzte die Straße nicht an die Fläche, wobei ich zugeben muss, dass es eigentlich immer Interpretationssache sein kann, was man noch als zugehörig sieht. Wenn man dem Vergröberungslager angehört dem jedes Details ein Dorn im Auge ist auf dem Weg, möglichst große Gebiete in JOSM laden zu können, dann wird man wohl auch noch das Gebüsch jenseits von Leitplanke, Bankett und Entwässerungsgraben als Teil der Straße (oder des Walds oder Felds, wie hier auch schon erwähnt) sehen können. Da es hier wohl unterschiedliche Ansichten gibt kann ich nur hoffen, dass wenigstens genug Respekt für die Arbeit anderer da ist, um nicht die Details anderer absichtlich zu löschen, damit die Nodedichte gering bleibt. Mal ein Bsp. Wir haben einen großen Wald, eine Straße geht mitten durch, Dann werden wir wohl den Wald als eine Fläche zeichnen und die 1. Straße durch die Fläche durch. Hier macht es keinen Sinn den Wald entlang der Straße aufzuschneiden und dann parallel zur Straße 2 Waldgrenzen zu zeichnen. doch, macht m.E. gelegentlich Sinn und mache ich dann auch. So genau ist die Grenze eines Waldes sowieso nicht definierbar (Endet der Wald am letzten Stamm oder am Ende der Kronen, die ggf. über die Straße ragen,...). so genau in der Tat nicht, wenn Du Dir mal einen echten Wald ansiehst wirst Du aber bemerken, dass es in der Realität weitaus größere Schwankungen gibt als nur der halbe Kronendurchmesser eines Baums. In der klassischen Kartenwelt gibt es u.a. 2 Arten von Karten, Landkarten und Katasterkarten. OSM ist meiner Meinung nach mit ersteren vergleichbar. -1, OSM ist sicherlich nicht mit einer Karte in einem bestimmten Maßstab vergleichbar, und hier sehe ich auch die Ursache in der Diskussion hier bzw. allgemein in der Diskussion mit Leuten, die gerne die Details in OSM begrenzen wollen: eine Datenbank sollte man nicht mit der gerenderten Karte in einem bestimmten Maßstab verwechseln. Wenn wir Katasterkarten machen wollen müßen wir ganz anders vermessen, da reichen GPS oder Stabilder nicht aus. Die meisten von uns mappen per GPS indem sie auf der Rechten Fahrbahn fahren oder sogar auf dem Bürgersteig gehen und zeichnen danach die Straße ein, ob sie dabei immer den Abstand zur Mittellinie korrigieren bezweifel ich. der nächste kann das dann richten, ist ja iterativ. Wir haben heute großflächig gute Luftbilder die eine ziemlich hohe Genauigkeit ermöglichen, mit GPS keineswegs vergleichbar (aber auch schon vorher war das Credo, sich nicht sklavisch nach dem GPS zu richten, s.z.B. relative Genauigkeit). Beim Routing spielen Flächen (ausser der Rand von highway-Flächen) sowieso keine Rolle, die können da verbunden sein oder nicht. Es sei denn sie sind das Ziel, dann sucht der Router eine Verbindung zwischen Fläche und Straßenraum. wenn es keine Verbindung gibt nimmt er das nächstgelegene Ziel auf einer Straße. Wir zeichnen Hausnummern oder Telefonzellen ja auch nicht auf die Straße sondern daneben, auch wenn gerade Telefonzellen sich praktisch immer auf dem Gehweg befinden (und der ist im OSM Modell derzeit Teil der Straße). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine Relation aus der Not
Am 22. August 2011 20:48 schrieb Albrecht Will albrecht.w...@online.de: Euer Vorschlag mit relation=site hat was. Leider ist diese Relation noch nicht am Laufen. wie meinst Du das? Es gibt davon derzeit 128714 Stück. Ich werden mal die Flächen doch löschen und das Ganze als leisure=park und tourism=zoo eintragen. Du kannst z.B. auch die Flächen alle in eine Multipolygon-Relation aufnehmen und dieser tourism=zoo, einen Namen, etc. mitgeben, ohne bei den Einzelflächen Informationen zu löschen, die sich darauf beziehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] living_street + alley?
Am 22. August 2011 10:43 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Peter peter@gmx.net wrote: Ich fand highway=living_street von Anfang an bescheuert. In 99% der Falle in Deutschland sind das ganz normale residential roads. Die Tatsache, dass das eine Spielstraße ist sollte in einen eigenen Tag. +-0 es spielt im Grunde keine Rolle, idealerweise machen es aber alle gleich ;-) Wo Platz ist für einen Reitweg und 5 Klassen von Verbindungsstraßen kann eine verkehrsberuhigte Zone auch nicht schaden, andererseits werden Kraftfahrstraßen anders behandelt und es scheint mittlerweile auch zu funktionieren (zumindest anfangs wurde man mit dem Rad da trotzdem draufgeleitet, weil der Tag nicht ausgewertet wurde). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 23. August 2011 02:02 schrieb Christian Müller cmu...@gmx.de: Am 22.08.2011 19:35, schrieb M∡rtin Koppenhoefer: Gegenfrage: wieso sollte man es beim Rendern dem Zufall (der Straßenbreitendarstellung) überlassen, wo eine Fläche aufhört? Was soll daran besser sein, wenn der Park auf dem Gehweg oder im Rinnstein endet anstatt dort, wo er tatsächlich zu Ende ist? Gerade beim Rendern von großen Zoomstufen ist es doch erwüscht, auch Details erkennen zu können, eine Vergrößerung der Flächen potentiell bis zur Straßenmitte (wenn man nur ein Haarlinie rendert oder die Straße ganz weglässt) schadet mehr als sie vermeintlich nützt. war hier nicht das credo, dass wir nicht für renderer taggen? es geht mir nicht primär ums Rendern sondern darum, dass Flächen dort eingetragen werden, wo sie sind. Das leitet sich m.E. aus dem Flächenmodell so ab. und der Renderer überlässt nichts dem Zufall, er rendert an der Stelle die Fläche, an der die Straße aufhört. wo die Straße aufhört ist sehr selten klar, da keine Breitenangaben oder Angaben zu weiteren Bestandteilen der Straße in den Daten vorhanden sind. Es ist nicht einmal klar, welche Teile der realen Straße der osm-highway tag beschreibt, allerdings könnte man argumentieren, es handele sich um die komplette Fahrbahn (seitliche Barrieren und Teile dahinter würde ich eher nicht dazurechnen, zumindest habe ich noch nie gesehen, dass die jemand im width-Tag angegeben hätte). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf BILD.de
Am 18. August 2011 17:14 schrieb Wolfgang wolfg...@ivkasogis.de: aber die einzigen, die konkret dagegen vorgehen könnten, sind die Lizenzverweigerer. Allen anderen wäre im Hinblick auf die Lizenzumstellung und die Aufforderungen an (Noch-)Nicht-Zustimmer widersprüchliches Verhalten vorzuwerfen, was wahrscheinlich zum Verlust des Anspruchs auf das by-sa führen würde. Wer den CT zugestimmt hat, hat der OSMF ein nicht exklusives Recht an den Daten übertragen, so dass die OSMF gegen Lizenzverstöße vorgehen kann/könnte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin GPSmap 62 ....
Am 15. August 2011 11:42 schrieb NopMap ekkeh...@gmx.de: Leider hat das 62 nicht den genialen Empfang den die alten 60er hatten. +1 auch mit neuester Firmware finde ich die Bedienung darüberhinaus völlig unbefriedigend. Beim alten 60er hat man alles im Griff, kann z.B. sofort sehen, ob man gerade loggt oder nicht, und kann das auch bequem jederzeit an- und ausschalten, während man beim neuen 62er weniger Optionen hat. Einzelne Waypoints nachträglich zu editieren (oder z.B. einzelne löschen) geht AFAIR überhaupt nicht. M.E. völlig unverständlich, wieso die eine gute Bedienung so kaputt gemacht haben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 14. August 2011 15:57 schrieb Bartosz Fabianowski bart...@fabianowski.eu: Es gibt hier keinen etablierten Standard. leider ;-) Das gängige Argument fürs Aneinanderkleben ist daß die Landnutzung da anfängt wo die Straße aufhört. ja, wobei hier m.E. Äpfel mit Birnen gemischt werden. Korrekte Flächen sind nunmal die, die den wahren Umriss beschreiben. Das Gegenargument dazu ist daß wir ja nur die Mittellinie der Straße mappen. Die Landnutzung dagegen fängt erst am Wegesrand an. Ein Aneinanderkleben ist daher IMHO geographisch nicht korrekt. ja eben Zudem macht es das Editieren schwieriger. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 14. August 2011 16:40 schrieb Christian Müller cmu...@gmx.de: Am 14.08.2011 15:57, schrieb Bartosz Fabianowski: Wegesrand an. Ein Aneinanderkleben ist daher IMHO geographisch nicht korrekt. Geographisch evtl. nicht, topologisch hingegen schon. M.E. sollte man für die Topologie-Fanatiker eine Relation oder irgendwas einführen, damit die Graphen-Flächen-Inkompatibilität überwunden wird. Flächen bewusst falsch zu zeichnen, damit sie mit dem Graphen-Modell der Straßen topologisch verbunden sind, sehe ich als Irrweg. Erst recht, da dadurch das Editieren fehlerträchtig und umständlicher wird. Der Wegesrand beginnt, topologisch gesehen, links und rechts des Weges, welcher in OSM durch eine Linie repräsentiert wird. wobei es hier nicht darum ging, den Wegrand zu mappen, sondern um angrenzende Flächen. Vorteile: - kein Niemandsland zwischen Straße und Gebiet m.E. kein Vorteil, das gaukelt nur Vollständigkeit vor, wo eigentlich Details hingehören (könnten) ;-) - mehr Übersicht im Editor (vgl. tausende nodes an einer Kreuzung) m.E. das Gegenteil: völlig unübersichtlich, da alles auf eine Linie läuft, auch wenn es gar nicht zusammengehört. Eine Linie für ein Objekt ist m.E. übersichtlicher. - weniger nodes das stimmt, aber ist nicht unbedingt ein Vorteil, es sind dadurch ja auch weniger Informationen enthalten. - geringere DB Größe / weniger Ressourcenverbrauch ja, am kleinsten wird sie, wenn man alles löscht ;-) - das ist z.B. interessant, wenn ein großes Datenset in den Editor geladen wird, oder man die Daten für mobile Geräte fit machen möchte dazu braucht man Informationen nicht weglassen: Editoren könnten auch mit größeren Datenmengen umgehen, wenn sie dafür optimiert werden und für mobile Geräte muss man die Daten sowieso konvertieren, d.h. dass man da ansetzen könnte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 15. August 2011 02:14 schrieb Christian Müller cmu...@gmx.de: Um nochmal auf den Zaun zurückzukommen. Einfach gesprochen, wenn der eine Fläche einsäumt, lassen Mapper m.W. auch keinen Platz zur Fläche - hier ist das Verkleben ein Automatismus. Die Ausnahme ist hier nur die Straße, wo einige behaupten, der Mittelgraph wäre die Fläche (m.E. wird man irgendwann - und einige machen das jetzt schon - Straßen zusätzlich als Fläche eintragen, und dieses Thema löst sich von selbst), bei Zäunen gibt es kein Problem. Wir taggen den way mit barrier=fance und die Fläche, die er umschließt, auf demselben way mit landuse=* - da gibt es auch kein Niemandsland dazwischen. das ist nicht unbedingt so: Spaghetti-Mapping geht sicherlich so, aber man kann auch zweimal denselben Weg zeichnen, einmal als Line-Feature (Zaun) und einmal als Flächenfeature (Landuse, leisure, natural, etc.), was dann für Klarheit sorgt, wenn man weitere Tags ergänzt (z.B. name, wo ein Mensch noch einigermaßen sicher sagen kann, dass sich das wohl auf die Fläche bezieht, ein Computer es aber u.U. auch auf den Zaun beziehen würde). Als Verbesserung dieser Methode würde man anstatt eines doppelten Weges ein Multipolygon für die Fläche verwenden (mache ich persönlich z.B. so). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wieder mal - Flächen und Wege
Am 21. August 2011 20:06 schrieb Dimitri Junker o...@dimitri-junker.de: Zeichnet man dagegen eine parallele Linie zur Straße als Flächengrenze geht die Beziehung zwischen beiden verloren. sofern es ausser der Nähe eine Beziehung gibt. Die räumliche Nähe hast Du ja in jedem Fall, wenn Du aber die Fläche vergrößerst, damit sie topologisch in das Straßenmodell passt, dann muss jeder, den die Fläche interessiert, erstmal nachsehen, welche Straßen noch Kanten mit der Fläche teilen, und dann (falls es dort eine Breite geben sollte) die Straßenfläche abziehen. Man müßte also dann eine Relation o.ä. machen um Fläche und Straße zu verknüpfen. wäre sicher am Eindeutigsten, wo es zutrifft, z.B. um Plätze in der Stadt an Straßen anzubinden, pauschal würde ich aber gar nicht unbedingt davon ausgehen, dass die Flächen die zur Zeit in OSM gezeichnet sind, die Straße begrenzen. Wenn man das grundsätzlich annehmen wollte, könnte man das auch über die Nähe berechnen. Ohne diese Verknüpfung könnte ein Renderer z.B. nicht wissen das er die Fläche unabhängig vom Zoomlevel immer bis an die Straße zeichnen soll Fürs Rendern gibt es in der Praxis m.E. kein Problem, (ausser die Fläche endet richtig weit von der Straße entfernt, dann wird man das auch sehen wollen), da wir die Straßen in den meisten Zoomleveln grafisch deutlich überhöhen. Beim Routing spielen Flächen (ausser der Rand von highway-Flächen) sowieso keine Rolle, die können da verbunden sein oder nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baumreihen, Alleen an Straßen
Am 11. August 2011 23:26 schrieb Christian Müller cmu...@gmx.de: Am 11.08.2011 21:13, schrieb Albrecht Will: OSM sammelt Daten der Realität. +1 Auf dein Beispiel bezogen: Ein Baum der Allee könnte fehlen, nicht alle Bäume haben evtl. den gleichen Abstand, etc. pp. Weiterhin, wenn Du mit +1 natural=tree_row denotation=avenue m.E. kann man gleich einzelne Bäume mappen natural=tree denotation=avenue Das geht praktisch genauso schnell, zumindest bei Kurven ;-) wie parallele Linien, und ist viel realistischer und lässt sich bei Bedarf auch viel besser (auch einzeln) verfeinern. Man braucht allerdings rel. gute Luftbilder (die es mittlerweile oft gibt). Es gab eine ganze Zeit lang viele Proposals, welche zum Ziel hatten, die Erfassung von Linienbündeln zu vereinfachen. ... Andere waren dafür, selbst für jede Fahrspur eine Linie zu erfassen und den gemeinsamen Bezug über eine Relation darzustellen. Heute ist ein Mix in OSM zu finden - naja, beides ist eher noch nicht in OSM angekommen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baumreihen, Alleen an Straßen
Am 10. August 2011 14:38 schrieb Christian Müller cmu...@gmx.de: Vereinzelte Bäume taggst Du mit natural=tree auf nodes. +1, solange man das vereinzelte nicht ausgrenzend meint, sondern im Sinne von einzelne. Für Alleebäume ist ausserdem denotation=avenue vorgeschlagen (als Zusatz). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Geräte aus den Staaten
Am 9. August 2011 19:42 schrieb Henning Scholland o...@aighes.de: Netzteil gibts nicht. Gewährleistung weiß ich net, wie Garmin sich da muckt. Ob das den Aufwand und die Zeit, die dann dein Bekannter beim Zoll verbringen darf und deinen Aufwand die Ersparnis rechtfertigt??? Lohnen dürfte sich das evtl. dann, wenn man es selbst mitbringt. Problem ist aber z.B., dass man das Gerät evtl. patchen muss, damit man deutsch als Sprache einstellen kann (ist nicht besonders schwierig, aber vielleicht nicht ganz legal?). Auch ist die eingebaute Basemap dann vermutlich Nordamerika und nicht Europa (habe selbst so ein amerikanisches 60csx, vor 3 Jahren war das trotz Zoll noch deutlich attraktiver). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer noch state of the art?
Am 3. August 2011 16:04 schrieb Andreas Tille andr...@an3as.eu: Die in dem anderen Mail beschriebene Methode der Aufspürung von Lücken per Relation Sortieren ist mir unklar. Eventuell könnte man sowas innerhalb von JOSM noch leicht eleganter lösen als mit der Web-Anwendung, aber eigentlich ging's schon ganz gut mit dem RA. In JOSM geht das Finden von Lücken so: 1. Relation im Relationeneditor öffnen (z.B. eines der Member anclicken und im tag-Fenster den Relationen-Eintrag auswählen und den Bearbeiten-Button anklicken). 2. Ggf. noch nicht geladene Member nachladen (Button links im Relationeneditor). 3. Im Relationeneditor linke Seite den Sortieren-Button anklicken (A-Z). Es sollten vorher alle Member der Relation geladen sein. 4. Die rechte Spalte der einzelnen Way-Member zeigt an, welche Ways miteinander verbunden sind und wo evtl. noch Lücken sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Digitalradio.de - Karte ohne Attributierung?
Schlimmer noch: Es werden die Tiles vom Hauptserver gezogen. Das mit dem Tileserver verstehe ich nicht - entschuldigt, aber damit habe ich mich noch nicht so recht beschäftigt. Wo ist da das Problem bzw. was ist der Vorteil, den anderen Server zu verwenden? der Tileserver auf OSM.org ist ein Service für die Mapper und eine Demo, was in unseren Daten steckt. Die Nutzungsbedingungen sind hier: http://wiki.openstreetmap.org/wiki/Tile_usage_policy Für private Seiten mit wenigen Zugriffen kann man den Dienst nutzen, aber wenn man eine professionelle Seite mit vielen Zugriffen betreibt, darf man das nicht mehr. Dann sollte man entweder einen Tileserver von Dritten benutzen (mapquest erlaubt z.B. die Nutzung, daher der Hinweis darauf), oder einen eigenen Server aufsetzen. Und Mapquest ist doch ein kommerzieller Dienst, wenn ich das richtig sehe? die Nutzung ist kostenlos, betrieben wird das von AOL. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gab es in einem Bereich schon einmal Nodes?
Du könntest z.B. in Potlatch1 u drücken und sehen, ob nach einigem Warten ein paar rote (=gelöschte) Ways auftauchen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gab es in einem Bereich schon einmal Nodes?
Am 2. August 2011 12:53 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Du könntest z.B. in Potlatch1 u drücken und sehen, ob nach einigem Warten ein paar rote (=gelöschte) Ways auftauchen. Sorry, Du suchst wohl nodes? PL1 findet nur ways. Versuchs mal mit OWL: http://matt.dev.openstreetmap.org/owl_viewer/map auf die Stelle sehr weit reinzoomen und das tile anclicken. Alternativ: Einen alten Planet runterladen und mit Osmosis die Stelle ausschneiden, die Dich interessiert. Dann z.B. in JOSM öffnen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche MaxHeight wird angegeben ?
Am 29. Juli 2011 11:16 schrieb Wolfgang wolfg...@ivkasogis.de: ja klar, aber wenn sein Fahrzeug schmaler ist als 4 m (2,50m ist AFAIK die Maxbreite für reguläre Fahrzeuge) dann würde er vielleicht noch durchkommen, aber laut Daten schon nicht mehr. Er soll sich aber nicht ins Guiness-Buch der Rekorde für das höchste Fahrzeug, dass jemals diese Unterführung passiert hat, qualifizieren, sondern da heil und sicher durchkommen. Deshalb in ausreichendem Abstand von der Mitte mit etwas Sicherheit (*abrunden*) messen. Wenn die Durchfahrtshöhe auf 4m Breite ausreicht, wird der Fahrer mit dem 2,50m breiten Fahrzeug durchkommen, es sei denn die Durchfahrt liegt in einer scharfen Kurve. M.E. ist 4m Breite zu viel Toleranz da normale Fahrzeuge nicht mehr als 250cm haben dürfen und tatsächlich auch noch etwas weniger haben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche MaxHeight wird angegeben ?
Am 28. Juli 2011 08:03 schrieb Georg Feddern o...@bavarianmallet.de: um diese Fälle abzudecken zu können, müsste man tatsächlich eine math. Formel angeben hatte ich ja geschrieben: Bogenform. Üblicherweise wird es ein Korbbogen (mit 3 oder 5 Einsatzpunkten) oder alte Bögen evtl. Spitz- oder Rundbogen sein. Damit kann man in Verbindung mit der Scheitelhöhe und der Basisbreite schon mal ganz ordentlich abschätzen, ob man durchpasst oder nicht. Andere Bogenformen auch hier: http://de.wikipedia.org/wiki/Bogen_(Architektur) - oder die maxheight in Abstufungen zur gegeben Breite angeben z. B. maxheight:forWidth2=x, maxheight:forWidth2.5=y, maxheight:forWidth3=y usw. Wenn man sich dann noch auf ein einheitliches Format einigen könnte, dann könnte man das evtl. sogar auswerten. ja, die Auswertung dieser Syntax wäre schön einfach. Maxheight ist dann allerdings, sofern es keine Schilder gibt, nicht der richtige Tag, da es die rechtliche Zulässigkeit und nicht die tatsächliche Geometrie beschreibt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Altitude im Wiki
Da diese Seiten wohl auf deutschsprachige Initiative entstanden sind, melde ich mich mal hier. Brauchen wir diese Seiten im Wiki? http://wiki.openstreetmap.org/wiki/Altitude m.E. ist alt für Höhendaten auf der Oberfläche nicht sinnvoll, es gibt ja bereits ele dafür. Was haltet Ihr davon, das jeweils in ele zu ändern? alt ist praktisch nicht in Gebrauch: http://taginfo.openstreetmap.org/keys/alt#values und darüberhinaus bietet es Verwechslungspotential mit alt für alternative. s.z.B. hier: http://taginfo.openstreetmap.org/keys/ref%3Aalt#values Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche MaxHeight wird angegeben ?
Am 27. Juli 2011 15:03 schrieb Jan Tappenbeck o...@tappenbeck.net: wenn man eine Bogendurchfahrt hat, dann ist am Rand die Durchfahrtshöhe anders als in der Mitte (idr). Wie würdet Ihr dieses bei maxheight anschreiben ? Du könntest den mittleren Wert als maxheight an den highway setzen und an der niedrigen Stelle einen Node setzen mit dem maxheight der seitlichen Höhe (ggf. für die Durchfahrt auch einen Way zeichnen, der die 3 nodes verbindet, z.B. barrier=entrance, bzw. wenn Du die Mauer schon hast dann den Durchfahrtsteil absplitten und mit barrier=entrance taggen). Alternativ müsste man ein Proposal machen, wie man das alles parametrisch (mit Breite, Bogenform und mittlerer sowie seitlicher Höhe) an einen Node hängen kann. Beides wird natürlich derzeit AFAIK nirgends ausgewertet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: gibt es ein Werkzeug - Flächen zu prüfen
Am 27. Juli 2011 14:26 schrieb fx99 f...@vollbio.de: sieht für mich auch gut aus. Hab den Weg mal in ein MP reingepackt, auch da heißt es geschlossen! JOSM kann seit kurzem auch darstellen, ob ein Weg geschlossen ist (sieht man am Icon z.B. im Selection-fenster) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Prozess auf Heimserver starten
Am 27. Juli 2011 20:37 schrieb Frederik Ramm frede...@remote.org: nohup meinprogramm.sh oder Du installierst Dir screen, das ist etwas komfortabler, weil Du da beim Wieder-Einloggen wieder die gleiche Shell-Sitzung zurueckholen kannst und so direkt siehst, was das Programm evtl. ausgegeben hat. nachdem man sich durch die 2500 Zeilen manpage gelesen hat ;-) Man kann übrigens auch bereits laufende Programme anhalten und in den Hintergrund schicken: mit strg+z hält man das laufende Programm an mit bg 1 (oder einer anderen Nummer, je nach Ausgabe von jobs) kann man den Befehl dann in den Hintergrund schicken, mit fg 1 wieder hervorholen. jobs zeigt die Befehle mit Nummern und Status (angehalten/fertig/etc) an. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche MaxHeight wird angegeben ?
Am 28. Juli 2011 00:33 schrieb Wolfgang wolfg...@ivkasogis.de: Wenn nichts dran steht und die Höhe 4m unterschreitet, ca. 2m von der Mitte auf beiden Seiten messen und den niedrigeren Wert abgerundet übernehmen. Der Fahrer eines entsprechenden Fahrzeuges sollte mit der Problematik vertraut sein und da dann heil durchkommen. ja klar, aber wenn sein Fahrzeug schmaler ist als 4 m (2,50m ist AFAIK die Maxbreite für reguläre Fahrzeuge) dann würde er vielleicht noch durchkommen, aber laut Daten schon nicht mehr. Gru0 Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiet
Am 26. Juli 2011 15:02 schrieb tshrub my-email-confirmat...@online.de: # Nationalparks (class 2) mit ?? = nationalpark (weiß grad nicht) falsch! das kann man nicht _ergänzend_ nehmen, da nicht 2x ein Schlüssel (boundary) verwendet werden darf. man kann aber problemlos 2 multipolygon-relationen erstellen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiet
Am 25. Juli 2011 20:09 schrieb Michael Bemmerl osm-t...@mx-server.de: Markus schrieb: Wie schreibt man Betreten verboten in die DB? Wie wär's mit access=no? Braucht man das? Den genauen Status geben doch die Tags für das Naturschutzgebiet schon an, access=no ist so unscharf, dass man es hier m.E. besser weglässt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3x3D // Re: 3D-Objekte aus Umgebungsbildern
Am 26. Juli 2011 20:50 schrieb Markus liste12a4...@gmx.de: Ich dachte dabei an Tags wie Farbe der Wand/des Dachs, Dachform, Höhe bei Gebäuden, deren Umrisse bereits erfasst sind. Ist so etwas schon einmal diskutiert worden? Ja, Martin Koppenhöfer hat sich dazu viele Gedanken und ein Datenschema gemacht. Die Initiative ging von Marek aus, der verschiedene Baumtypen zur parametrischen Modellierung sowie Brückentypen vorgeschlagen hat. Im Bereich building und Unterseiten (und proposals) gibt es im Wiki auch schon ein paar Konzepte, wobei das nicht alles gleich gut funktioniert. Einen Anfang für das Konzept einer parallelen und eng verknüpften 3D-Datenbank gibt es hier, ist aber noch eine frühe draft-Phase: http://wiki.openstreetmap.org/wiki/OSM-4D Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3x3D // Re: 3D-Objekte aus Umgebungsbildern
Am 27. Juli 2011 02:01 schrieb RalfGesellensetter r...@gmx.de: Am Dienstag, 26. Juli 2011 schrieb Markus: Ja, Martin Koppenhöfer hat sich dazu viele Gedanken und ein Datenschema gemacht. Danke, Martin, Walter und Markus! bevor hier bei manchen ein falscher Eindruck entsteht: es gibt unzählige Beiträge zum Thema 3D und OSM, es gibt sogar einen Viewer von der Uni Heidelberg um OSM in 3D anzusehen: http://wiki.openstreetmap.org/wiki/DE:OSM-3D Mein Verdienst ist das alles nicht ;-) Startpunkte für eine Recherche könnten z.B. die Seiten in der 3D-Kategorie sein: http://wiki.openstreetmap.org/wiki/Category:3D Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen per Bing?!
Am 25. Juli 2011 14:28 schrieb Frederik Granna webmas...@granna.de: Ich meinte eher diese History: http://www.openstreetmap.org/browse/way/22965249/history . genau die zeigt ja den Changeset-Kommentar an, wenn er denn gesetzt wird (wie Du in Deinem Beispiel z.B. an der Version 12 sehen kannst). Je genauer man dort einträgt, was man weshalb gemacht hat, um so mehr wird auch dem nächsten Mapper klar, was gelaufen ist. Wenn man wie sysrun einfach nichts schreibt, ist das halt wenig hilfreich. Ein Beispiel könnte z.B. sein: D-Brandenburg, Tracing roads from Bing, no local knowledge oder so. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen
Am 24. Juli 2011 09:09 schrieb Walter Nordmann walter.nordm...@web.de: access=private, wie in der Dornbreite 247ff, bitte nur, wenn da wirklich ein Schild privat steht. privat-Durchgang verboten müsste da m.E. stehen (wenn da nur Privatstraße steht, dann heisst das noch nichts für den access, der kann durchaus trotzdem rechtlich garantiert sein). Wobei eine Einfriedung (Zaun etc) auch ohne Schild und auch wenn das Tor offen steht eindeutig und verbindlich signalisiert, dass es sich um einen privaten Bereich handelt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer - Inselgruppe
Am 24. Juli 2011 18:26 schrieb Chris66 chris66...@gmx.de: man könnte das auch mit einer Multipolygon-Relation machen (type=multipolygon, place=archipelago) So wird es ja derzeit oft gemacht. Ostfriesische Inseln: http://www.openstreetmap.org/browse/relation/963669 Ist ok[1], solange die Inseln klein sind und die Coastline jeweils nur aus *einem* Way besteht. http://www.openstreetmap.org/browse/relation/1382469 (Die Relation lädt bei mir jetzt schon seit 5 Minuten) das liegt daran, dass die db sich alle Members zusammensuchen muss, und würde sich mit einem anderen Relationstyp auch nicht ändern. [1] Wobei MPs eigentlich dazu gedacht sind Polygone mit Löchern zu definieren, nicht um Objekte zusammenzufassen. Das ist ein Mythos. Multipolygone sind Konstrukte, um aus ways Polygone zu definieren. Die Mindestanforderung ist ein outer way. Löcher braucht man nicht, wenn man sie hat braucht man allerdings Multipolygone. Für das o.g. Beispiel Inselgruppe kann man mit einer Multipolygonrelation ein Objekt (die Inselgruppe) konstruieren, das aus mehreren für sich geschlossenen Polygonen besteht, und diesem dann die entsprechenden Tags zuweisen (Inselgruppe, z.B. natural=archipelago, name=foo) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place
Am 24. Juli 2011 20:05 schrieb Chris66 chris66...@gmx.de: Am 24.07.2011 19:55, schrieb M∡rtin Koppenhoefer: Doppelte Erfassung sollte vermieden werden. die Erfassung mit Node und Polygon nicht doppelt, sofern man das über eine Relation zusammenbringt. Welchen types ? egal, das ist von Relationentyp völlig unabhängig. Zugegebenermaßen ist für MP-Relation derzeit kein label-node vorgesehen, aber das könnte man ja ändern, ansonsten könnte man z.B. eine place-relation erfinden, die site-relation passt definitionsgemäß m.E. nicht, hätte aber einen label-Node in ihrer Definition. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer
Am 23. Juli 2011 17:26 schrieb Markus liste12a4...@gmx.de: @ Frederik: Die Punkte durch Küstenlinen zu ersetzen erscheint mir sinnvoll. was Punkte und Polygone angeht, ist die Lage nicht ganz so offensichtlich, wie sie vielleicht scheint. Bei den Bundesländern bspw. scheint es so, als ob sich beides durchgesetzt hat. Der Node wird in die Relation als Rolle label aufgenommen. Auch bei anderen Places wie Städten macht es wohl doch Sinn, auch einen Node zu haben, da sich nur aus dem Polygon dass (politische/topografische/strukturelle) Zentrum nicht unbedingt ergibt. Du schreibst: die Kuestenlinie wird beim Standard-Import ja rausgeworfen. Was bedeutet das? wird eine Küstenlinie an sich nicht gerendert? nur wenn da noch weitere Attribute dranhängen? warum? gemeint ist, dass osm2pgsql im standard-Stil natural=coastline nicht importiert (wenn da nicht noch was dran hängt, was doch noch zum Import führt). Das deshalb, weil sie nicht gebraucht werden. Die Küstenlinien (bzw. eigentlich die Landmasse) rendert mapnik mit Hilfe von Shapefiles, die vorher schon aus den OSM-Daten generiert werden (so wird besser sichergestellt, dass die Polygone geschlossen sind und das Land nicht überflutet wird). Seit einiger Zeit ist allerdings eine Option eingebaut, um die Küstenlinien doch zu importieren. Wenn der Renderer flächengrössen-abhängige Regeln kann, dann wäre das m.E. ein erster Ansatz, Inselnamen klassifiziert zu rendern. das geschieht bereits. Wobei dann noch die Problematik mit der Dominaz zu lösen wäre: Mit Dominanz meine ich: - geografische Bedeutung bezüglich der Umgebung - Entfernung zwischen Inseln bzw. zwischen Insel und Küstenstädten - Bedeutung (politisch, wirtschaftlich, etc) in Bezug zu anderen Orten Diese Dominanz ist (noch?) nicht klar, d.h. um das zu machen bräuchte man zusätzlich zu den bisher weitgehend fehlenden Daten auch erstmal eine Festlegung, was man wie werten und gewichten will, vor allem erstmal welche Indikatoren überhaupt berücksichtigt werden sollen. Als Anhaltspunkt und einigermaßen verbreitet könnte man die Einwohnerzahlen nehmen, ggf. in Kombination mit der Fläche und solchen Dingen wie ob es sich um eine Verwaltungszentrum / Hauptstadt handelt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene Karten rendern
Am 20. Juli 2011 12:04 schrieb Andreas Tille andr...@an3as.eu: Wenn irgendwer derjenige ist, der das Privileg hat, seine Karte als Default auf osm.org dargestellt zu bekommen, dann muß er damit rechnen, daß es Leute gibt, die Fehler finden und den Wunsch äußern, daß sie korrigiert werden. Für sowas sollte eigentlich auch ein Bugtracking System her, in dem das Problem und die Diskussion dazu geloggt werden. Es ist ja soweit ich weiss grundsätzlich auch durchaus erwünscht, dass man konstruktive Verbesserungsvorschläge ins trac einstellt. Die URL ist trac.openstreetmap.org --- für die Mapnik-Render-Regeln muss man als Komponente mapnik auswählen. Klar ist aber auch, dass es die Regelmaintainer nie allen gleichzeitig Recht machen können, und von daher nicht jeder Vorschlag auch umgesetzt werden wird. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sommeraufgabe 2011
Am 19. Juli 2011 10:48 schrieb Chris66 chris66...@gmx.de: Also, es gibt ein Gebäude beschildert mit Kennedybollevard 302-654 (das heisst die Hausnummern sind Wohnungsnummern). wenn es Wohnungsnummern sind: evtl. ist addr:housenumber der falsche Tag (es gibt einen Vorschlag im Wiki für Wohnungsnummern)? Vermutlich meintest Du allerdings: jede Wohnung hat eine Hausnummer? Dieses hat mehrere Eingänge mit den entsprechenden Ranges: Eingang 1 : 302-352 Eingang 2 : 354-402 Eingang 3 : 402-446 etc. Ich könnte nun: (a) Jede Wohnung einzeln als addr:-Node mappen (ca. 100 Stück) ja, wenn Du dazu Lust hast ;-) (b) eine addr:interpolation quer über das Gebäude legen ja, bzw. mehrere (c) an den Eingängen Nodes mit: addr:housenumber=302-352 addr:interpolation=even ich würde momentan (c) bevorzugen, Nachteil: Nominatim kann vermutlich keine Single-Node-Interpolation. eher nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer
Am 19. Juli 2011 00:40 schrieb Markus liste12a4...@gmx.de: Eine Verfeinerung wäre abwärtskompatibel durch ein Zusatztag zB. island:level=1-10 oder so möglich. -1 Besser fände ich eine Klassifizierung nach gewichteten Messgrössen: - Fläche gibt es schon, man muss dazu die Insel als Fläche eintragen und nicht als node wie man es vielfach noch vorfindet - Einwohnerzahl gibt es schon: population - jährlicher Personenverkehr (Flugzeug, Schiff, Bahn) ist das eine Inseleigenschaft oder eine Eigenschaft der jeweiligen Straße/Schiene/Flughafen? M.E. letzteres. Wer so was auswerten will, kann sich das ja zusammensuchen, aber m.E. fehlen uns dazu überwiegend Quellen. - jährlicher Güterverkehr (Flugzeug, Schiff, Bahn) dito, s.o. - Dominanz was meinst Du damit? Auf die Fläche bezogen? Auf die Höhe über Meer? Auf die Einwohnerzahl? Auf das Durchschnittseinkommen? Auf das Steueraufkommen? Auf die Geburtenrate? Auf die Abwasserkosten? - Bruttosozialprodukt gibt es nur bei unabhängigen Inseln, nicht bei solchen, die Teil einer größeren Volkswirtschaft sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eBay Verkauf Seekarte ...
Am 19. Juli 2011 07:51 schrieb NopMap ekkeh...@gmx.de: Bedeutung der Lizenz hattest. Es ist völlig legitim, kostenlose OSM-Karten zu einem unverschämten Wucherpreis anzubieten, wenn man Dumme findet, die sie kaufen. :-) die Karten zu einem unverschämten Wucherpreis anzubieten halte ich nicht für legitim, legal und lizenzkonform ist es allerdings. Auf das oben verlinkte Angebot trifft Wucherpreis m.E. aber überhaupt nicht zu, die Karte wird inkl. Stick für 1,-EUR und 2,99 Versand angeboten, was daran Wucher sein soll erschließt sich mir nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse im Autobahn-Kreuz
Am 12. Juli 2011 06:27 schrieb Jan Tappenbeck o...@tappenbeck.net: Wenn das Area aber alleinstehend ist, dann kann man das später ggf. einfacher umtaggen als wenn es mit dem angrenzenden Bereich verknüft ist. Es spielt für das Ändern der Tags keine Rolle, ob und wie die Flächen verbunden sind. Das Verbinden der Flächen ist Teil der Topologie: wenn die Flächen im echten Leben verbunden sind, dann sollten sie es auch in OSM sein. Wenn sie nicht verbunden sind (also noch etwas Flächiges dazwischen ist), dann wäre es auch falsch, sie in OSM zu verbinden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Logicbot - Lizenz
Am 13. Juli 2011 00:33 schrieb Stefan Schwan stefan.sch...@googlemail.com: Diese Art der Änderung ist sicherlich nicht als schöpferische Leistung schutzwürdig und daher beim Aufräumen ignorierbar - es ist aber trotzdem extrem lästig, die inzwischen größtenteils gelben Wege zu checken! +1 Ich empfand die Aktion schon damals als Vandalismus und trage meine Boolean Werte nach wie vor als true und false ein. ja, es lebe der Pluralismus. Wieso sollte man sich auf einen Wert verständigen (yes ist 62mal so häufig wie true bei oneways) wenn man genausogut mehrere verschiedene Werte für dasselbe verwenden kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswirkungen der Lizenzumstellung auf Wegerelationen
Am 13. Juli 2011 11:46 schrieb Chris66 chris66...@gmx.de: Also mal abgesehen davon, dass an einer Routenrelation nun absolut gar nichts kreatives ist, Und Bing Abmalen ist dagegen kreativ? ja ist es. Abmalen halte ich alllerdings nicht für das richtige Wort. Lass mal 3 Leute dieselbe Gegend von einem Luftbild digitalisieren und vergleiche die Ergebnisse. Bei Gebäuden und evtl. Straßen mögen die noch sehr ähnlich sein, beim Rest aber ziemlich sicher nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesperrte Wege im Nationalpark Harz
Am 13. Juli 2011 22:16 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Peter peter@gmx.net wrote: Diese Wege tauchen bei zoom=13 auf, sind ab 15 dann gerötet. Das sehe ich als Bug, die kann man auch ab 13 rot machen. Verbotene Wege sollte man bei Feld Wald Wiesen Wanderwegen eher gar nicht darstellen Ich bin absolut dagegen eine solche Form von Selbstzensur zu üben. Gegen Zensur, ob selbst auferlegt oder von aussen, bin ich selbstredend auch, aber aus den genannten kartographischen Gründen könnte man durchaus überlegen, ob man Wege, die sowieso grundsätzlich nicht betreten werden dürfen, wirklich schon in Z13 darstellen will, dort aber die access-Attribute noch ignoriert, und erst in Z15 genauer darstellt, dass bestimmte Wege eben gar nicht genutzt werden dürfen. Oder ob man eben die Wege erst dann darstellt, wenn man auch genügend Platz hat darauf hinzuweisen, dass sie nicht benutzt werden dürfen. Bestimmte service werden (bzw. wurden) auch erst ab Z.15 dargestellt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer
Am 15. Juli 2011 14:26 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Für Inselgruppen fehlt hingegen noch ein Tagging-vorschlag (AFAIK), d.h. da könnte man helfen. Vorschlag für den Key: natural (das sehe ich als Hauptkey für geografische Features, s. dort z.B. was es schon gibt: Gipfel, Quelle, Höhleneingang, Strand, Bucht, etc.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer
Am 12. Juli 2011 16:23 schrieb Markus liste12a4...@gmx.de: Hier steht, dass man die Coastline der Insel mit place=island bezeichnen soll, plus den Namen dazu: http://wiki.openstreetmap.org/wiki/DE:Tag:place=island Wenn ich mir aber unsere Mapnik-Karte anschaue, funktioniert das nicht so richtig. Woher weiss Mapnik, wann eine Insel klein und wann sie gross ist? Wie können wir ihm helfen, das besser zu erkennen? wenn die Insel als Fläche und nicht als Punkt drin ist, dann hat Mapnik eine gewisse Vorstellung von der Größe (abhängig vom Breitengrad ist das nicht überall genau gleich). Für Inselgruppen fehlt hingegen noch ein Tagging-vorschlag (AFAIK), d.h. da könnte man helfen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesperrte Wege im Nationalpark Harz
Salü! genutzt werden (Nationalpark = Naturschutzgebiet). Eine Mitarbeiterin, die für die GIS-Daten zuständig ist, bemängelt, dass diese Wege in der OSM Karte enthalten sind und nicht entsprechend gekennzeichnet sind. In der offiziellen TK10 von Sachsen-Anhalt sind die Wege um den Brocken auch drin und da kann man keinen Unterschied zwischen öffentlich zugänglich oder gesperrt erkennen. Kann's vielleicht sein, dass die sich weniger an der Darstellung stören, als daran, dass da jemand zum Mappen über ihre gesperrten Wege gelaufen ist? Grüße Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geänderte Wegführung bei Radrouten
Am 11. Juli 2011 08:37 schrieb Andreas Tille andr...@an3as.eu: Das würde ich früher oder später wahrscheinlich mal ins Auge fassen, ändert jedoch nicht die Tatsache, daß die Schilder nach wie vor an der nicht mehr offiziellen Route angebracht sind. solange die Schilder da sind, würde ich die Route auf jeden Fall drinlassen (wenn sie auch so befahrbar ist, und vor allem auch angesichts der Tatsache, dass Du Dir selbst nicht sicher bist). Die Wegqualität hat sich ja nicht von einem Tag auf den anderen geändert. Ob und welche Route jetzt offiziell ist weisst Du nach Deinen bisherigen Mails auch gar nicht, das ganze beruht bisher nur auf einem Verdacht und alles nur Vermutungen. Wenn Du Gewissheit willst, könntest Du mal versuchen, jemanden auf dem Amt anzurufen (die schicken Dich da auch gern weiter, wenn sie nicht zuständig sind, mit ein bisschen Beharrung kommt man normalerweise an die Infos die man braucht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse im Autobahn-Kreuz
Am 11. Juli 2011 19:02 schrieb Robert S. osm-m...@autobahnen-europa.eu: 2011/7/11 Jan Tappenbeck o...@tappenbeck.net Die reine Fahrbahnfläche ist mit area:highway [1] zu erfassen; das geht aber eigentlich nur, wenn auch ausreichend hochauflösende Luftbilder verfügbar sind. kann man machen. ist zu erfassen finde ich beim derzeitigen Stand allerdings deutlich übertrieben (gerademal 474 Straßenstücke sind bisher so erfasst, das macht einer allein in rel. kurzer Zeit). Der ganze Straßenbereich bekommt dann landuse=grass ?? Da möchte ich gerne widersprechen: wieso sollte eine Straße landuse=grass bekommen? landuse ist m.E. highway oder ähnlich, surface dann je nachdem Asphalt, Schotter oder Gras. , weil ja nicht direkt an der Asphaltkante das Straßenbegleitgrün (Gebüsch/Strauchwerk/Bäume etc.) losgeht, sonder es immer einen Grünstreifen gibt der z.B. Beschilderung, Leitplanken oder auch einen Entwässerungsgraben aufnimmt. Eben. Gerade weil es diese ganzen Elemente gibt, ist landuse=grass für eine Straße doch Quatsch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 7. Juli 2011 16:04 schrieb Florian Lohoff f...@zz.de: Solange das alles landuse ist sehe ich noch ein das das sinn macht. Sehe bloss immer haeufiger noch einen mix aus highway, landuse, amenity building etc ... Dann hat man wirklich gar keinen ueberblick mehr. +1, ich sehe das genauso. Landuses würde ich am (geschätzten) Grundstücksende aufhören lassen und nicht mit der Straße verbinden. Das Verbinden sorgt für massenhaft Probleme und Intransparenz beim weiteren Mappen und hat auch hins. der transportierten Information Nachteile. Direkt angrenzende landuses nicht zu verbinden sehe ich hingegen als topologischen Fehler an, der ebenfalls vermieden werden sollte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 7. Juli 2011 17:25 schrieb Johannes Huesing johan...@huesing.name: M∡rtin Koppenhoefer dieterdre...@gmail.com [Thu, Jul 07, 2011 at 05:09:48PM CEST]: +1, ich sehe das genauso. Landuses würde ich am (geschätzten) Grundstücksende aufhören lassen und nicht mit der Straße verbinden. Und wenn die Straße zum Grundstück gehört, bei Feldwegen, Wegen durch Schrebergartensiedlungen und Waldwegen? Bei Feldwegen gehört die Straße AFAIK normalerweise nicht zum Grundstück, bei anderen Wegen muss man sehen. M.E. wird ein landuse nicht in der Mitte des Weges enden, er wird grundsätzlich am Rand enden, entweder man schließt den Weg mit ein, oder nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 7. Juli 2011 19:54 schrieb Robert S. osm-m...@autobahnen-europa.eu: Hat man hier in Aachen auch anfangs gemacht^^ Und dann andere Flächen nicht per Multipolygon ausgeschnitten sondern einfach drüber gezeichnet... Inzwischen ist das in ein Multipolygon überführt worde - wobei man die residential-Fläche zumindest an den Bahnanlagen aufteilen könnte. für die Mapper am einfachsten ist es, je Block bzw. falls erforderlich noch feiner, die Nutzung anzugeben. Wenn sich was ändert oder man andere Daten ermittelt kann man einfach und ohne die halbe Stadt zu analysieren oder herunterzuladen das tag für den einen Bereich anpassen, der einen interessiert. Argh! 1. Die Landnutzung ist flächendeckend. Schonmal zwischen einem Feld und einer Wiese einen Bereich gesehen, wo einfach *nichts* ist? Nein. Mich schüttelt es immer, wenn ich in den Daten oder auf den Karten solche 'weißen Kanten' sehe... weisse Kanten sind erstmal überhaupt nicht schlimm. Wenn man dem Ungenutzten eine Nutzung zuweisen will, kann man das ja gerne tun, aber es wird eben weder residential noch farmland sein, sondern so was wie Brache oder ungenutzt oder Abstandsfläche, etc. 2. Eine Erfassungsmethode ist nicht schon deshalb abzulehnen, weil sie Arbeit macht. klar 3. Die Erfassung von Landnutzung sollte schon vollständig erfolgen; also so, dass im Regelfall kein nachträgliches Einfügen mehr nötig ist. Eine unvollständige Erfassung von Landuse macht meist eher mehr Arbeit, als dass sie nützt. das halte ich für Quatsch. OSM funktioniert iterativ, und m.E. sollte man daran auch immer denken. Vollständig gibt es nicht. Das ist auch der Grund, warum m.E. kleinere Stückelungen größeren Flächen vorzuziehen sind: weil man sie viel einfacher weiter bearbeiten kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Daten im 50km Radius ermitteln
ich würde ein pbf z.B. von der Geofabrik laden welches das komplette Gebiet abdeckt und dann mit pbftoosm -b=12.62,42.3,13,42.56 eingabe.pbf ausgabe.osm eine BB ausschneiden. Geht rel. schnell und problemlos. Wenn Du wirklich einen Kreis brauchst kannst Du danach noch weiter schnipseln, oder vielleicht gibt es auch eine Polygon-Schneideoption, sieh Dir das mal im Wiki an. Es gibt auch noch alternative pbf-Programme. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 6. Juli 2011 10:50 schrieb Andreas Neumann andr-neum...@gmx.net: bevor ich einen Editwar beginnen, wollte ich nur klären, ob ich da falsch liege... Es geht darum, wenn mehrere Bänke an einem Platz stehen. Ich hab immer einen Node für jede Bank gesetzt. Nun geht ein User in Ilmenau durch und löscht die Bänke. Auf unserem Kirchplatz stehen jeweils Bäumchen mit Bänken, er machte daraus einen Baum mit Bank. Er verweist darauf, dass mehrere Bänke an einem Ort redundant sind und es ausreicht nur eine zu malen. Gibt es da eine Redundanz-Regel, die ich nicht kenne? hm, Baum und Bank auf demselben Node mag OK sein, aber bei mehreren benachbarten Bänken alle bis auf eine zu löschen ist m.E. Vandalismus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stammtische im Wiki-Terminkalender reduzieren?
Am 6. Juli 2011 09:47 schrieb Frederik Ramm frede...@remote.org: Was koennten wir tun, um die restliche OSM-Welt nicht so zu erdruecken? Sollten wir vielleicht einfach eine Extra-Kalenderseite Regular pub meets in Germany machen? Ja, man könnte die Pub-meetings nach Ländern sortieren und auf Unterseiten unterbringen. Andererseits ist das mit den Symbolen schon ganz gut gelöst, so dass man die wichtigeren Termine eigentlich auf einen Blick von den Stammtischen visuell unterscheiden kann. Ich finde es ist durchaus auch eine gute Werbung für die Community, wenn viele persönliche Zusammenkünfte dort eingetragen sind. Dass das meiste in Deutschland stattfindet ist ja kein Zufall, die Mapping-Community ist dort auch auch stärksten ;-), d.h. OSM spielt sich wirklich zu einem großen Prozentsatz in deutschen Kneipen ab, das kommt nicht nur dem Mexikaner so vor ;-) M.E. sind wir gerade so am Limit angekommen was die Länge der Liste angeht, d.h. die Unterseiten nach Ländern oder ein dynamisches Ausblenden auf der Hauptseite sind beides gute Ideen für die nahe Zukunft, wenn die Liste wie zu erwarten weiter wächst. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 6. Juli 2011 11:24 schrieb Falk Zscheile falk.zsche...@googlemail.com: Vielleicht könnt ihr euch ja darauf einigen, dass die nahe beieinander stehenden Bänke über eine site-Relation zusammengefasst werden. -1, wozu sollte das gut sein? Es ist ein Leichtes, nahe zusammenstehende Bänke _im Postprocessing_ zusammenzufassen, in den Daten will man die m.E. alle haben, und eine Relation erhöht unnötig die Komplexität (dass die in der Nähe stehen ist bereits in den Daten). Im übrigen ist das ein ungeklärtes Problem ob und welche Detailgrenzen/Abstraktionsgrad Daten haben sollten. M.E. regelt das der Mapper. Hinterher die Abstraktion in den Grunddaten (db) zu erhöhen halte ich für Vandalismus (*reiz*), vorhandene Daten in der eigenen db-Kopie zu abstrahieren ist ggf. wünschenswert. Solange man das aber noch einigermaßen mit GPS-Gerät erfassen kann ist meiner Meinung nach noch kein Platz für diese Diskussion :-) man kann sowas wie Bänke durchaus auch per Foto erfassen, und dann z.B. den ungefähren Abstand und die Lage erkennen, GPS ist da meistens eher nicht genau genug, ovn daher ist das m.E. auch kein Kriterium. Was die Abstraktion von Bänken grundsätzlich angeht macht man da ja schon einiges, sonst müsste man die Bänke als area oder evtl. als kurzen way eintragen, dann könnte man sich auch (analog zu cliff oder retaining wall) auf einen Standard einigen, wo die Rückenlehne falls vorhanden ist (bezogen auf die way-Richtung), und hätte die Information, wie die Bank ausgerichtet ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sommeraufgabe 2011
Am 6. Juli 2011 12:20 schrieb Jan Tappenbeck (OSM) o...@tappenbeck.net: [1] http://wiki.openstreetmap.org/wiki/DE:Sommeraufgabe2011 nette Idee, ich habe mal ein paar Hinweise für Italien ergänzt. Hast Du das auch im Forum gepostet? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 6. Juli 2011 11:53 schrieb Falk Zscheile falk.zsche...@googlemail.com: Aha, und das ist dann genauer/besser? Ich denke dieses Beispiel zeigt schön, dass hier irgendwo eine Grenze bei der Datengenauigkeit liegt. Klar gibt es eine Grenze bei der Datengenauigkeit, aber die besteht eben nicht nur in der absoluten Lage der Objekte sondern auch in der relativen Lage und in der Konfiguration. Z.B. macht es einen Unterschied, ob 5 Bänke in einer Reihe stehen, oder ob sie ein U bilden. Auch kommt es darauf an, auf welcher Seite eines Weges / Bushhaltestelle, Telefonzelle, Einmündung, etc. sie stehen (relative Lage). Das ist m.E. viel wichtiger als die genaue Lage auf den cm. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 6. Juli 2011 12:27 schrieb Sven Sommerkamp s_sommerk...@gmx.de: Würde man statt einem Waldstück jeden einzelnen Baum erfassen? Warum nicht? ja, warum nicht. Vielleicht mit Pilzbewuchs und ohne als Tag? warum nicht, wenn man Zeit, Lust und Interesse daran hat. Die Frage ist doch immer wieviel ist ausreichend und macht Sinn? Und ist ist das Konstrukt noch allgemein durchschaubar? ja, wobei das bei der Aufnahme wieder der einzelne Mapper entscheidet, während das Löschen m.E. mind. einen Dialog/Diskussion erfordert. Und wenn jemand einzelne Bäume gezeichnet hat ist es m.E. eben nicht OK, die alle zu löschen, eine Fläche drumrum zu malen und zu deklarieren, das war davor zu detailliert und zu wenig abstrakt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 7. Juli 2011 00:05 schrieb Stephan Wolff s.wo...@web.de: Wie könnte man z.B. bei einer Bushaltestelle mit Bank und Unterstand die Lage der drei Einzelobjekte (Haltestellenmast am Fahrbahnrand, Bank hinter dem Fußweg, Unterstand 5 m in Fahrtrichtung) abbilden ohne eine bestehende Auswertung zu schädigen? das kommt immer darauf an, wie die Auswertung aussieht, d.h. was wie ausgewertet wird. Soll man eine Straßeneinmündung mit drei kleinen Verkehrsinseln mit allen Details erfassen, wenn dadurch zehn zusätzliche Wegstücke und fünf zusätzliche Abbiegerelationen nötig werden? ja, m.E. sollte man die Details abbilden. Werden da wirklich so viele Abbiegerelationen notwendig? Wie kann der Mapper erkennen, ob es dann Probleme bei der TMC-Auswertung gibt? gefühlsmäßig würde ich vermuten, dass das keine Auswirkungen hat, aber ganz genau habe ich mir TMC noch nicht angesehen. Selbst wenn keine bestehenden Daten geändert werden müssen, erschweren drei eng benachbarte Linien anderen Mappern die Arbeit und provozieren falsch verbundene Wege. am einfachsten ist immer eine leere Karte zu editieren. Hat Deine Maus kein Zoomrad? Was ist eng benachbart? Das ist doch nur eine Frage, wie weit man reinzoomt. Fast jede Detailerfassung hat Vor- und Nachteile. Oft müssen wir mit den Nachteilen leben. Aber ich finde es legitim, auch Entscheidungen gegen Detailerfassung zu Gunsten eines einfacheren, generalisierten Datenmodells zu treffen. ich nicht, wenn man dafür die Details anderer Leute löscht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 5. Juli 2011 11:09 schrieb UMAX974 umax...@googlemail.com: Ja, und genau, da liegt dann mein Problem, an dem ich regelmäßig scheitere. Ich kenne JOSM und arbeite gerne damit, aber mkgmap ist für mich einfach ein Buch mit sieben Siegeln. Das Programm hat, wie man so schön sagt, keine usability. Kann man das Teil nicht so schreiben und gestalten, dass selbst Dummys wie ich damit einfach klarkommen? Als ich das das letzte Mal benutzt habe reichte es aus, das Programm mit entsprechenden Parametern auszuführen, der Rest ging automatisch (hatte allerdings einen kleinen Bereich gemacht, der kein Splitten erforderte). Es gibt mittlerweile Skripte, die AFAIK alles automatisch machen, sowohl für Win als für Linux. Sieh mal hier: http://mce66.altervista.org/software.html#Open_Maps_for_Garmin_navigators (das erste dort, bzw. Direktlink zur Windowsversion: http://mce66.altervista.org/software/IMG-OSM-Country/CreateIMG-beta06.zip ) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Windows: kacheln zippen und dann auf dem Server wieder entpacken
Am 5. Juli 2011 12:41 schrieb Jan Tappenbeck o...@tappenbeck.net: Am 05.07.2011 11:52, schrieb Frederik Ramm: Hi, On 07/05/11 11:46, Jan Tappenbeck wrote: Nun wende ich mich an Euch mit der Frage ob einer ein freies Packtool kennt das über Batch-Betrieb angesprochen werden kann und das dann auch mit einem entsprechenden Script entpackt werden kann - und das in dieser Konstellation auf funktioniert. Wenn ich Dich richtig verstehe, ist Dein Problem, dass Du kein Commandline-Auspacktool fuer Zip-Dateien auf Windows hast? Ich habe Windows Commandline Unzip in Google eingegeben und fand als ersten Treffer dies: http://stahlworks.com/dev/index.php?tool=zipunzip Hast Du das schon probiert? Bye Frederik hi ! ... umgekehrt - ich muss erst einmal auf windows7 packen und dann das richtige entpackscript auf dem zerver haben ! hast Du mir dem Teil schon einaml das Bündeln von Dateien in verschachtelten Verzeichnissen realisiert bekommen ?? such mal nach tar bzw. komprimiere dann mit bzip (tar.bz2). komprimieren mit bz2 geht z.B. so: tar -cvjf archivname.tar.bz2 zusicherndedateibzwordnername Entpacken auf dem Server sollte so gehen: tar -xvjf dateiname.tar.bz2 Das ist rekursiv, d.h. die Ordnerstruktur wird beibehalten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 5. Juli 2011 12:05 schrieb UMAX974 umax...@googlemail.com: Hm, Aber der Mac ist wieder außen vor... ;( - Oder gibt es auch für den was? Müsstest Du mal im App-Store nachsehen (SCNR). Im Ernst, evtl. geht das Linux-Script auch auf dem Mac. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 6. Juli 2011 00:15 schrieb Wolfgang wolfg...@ivkasogis.de: das width-tag willst Du wo genau anbringen? damit ließe sich die Breite des Bereiches zwischen den Fahrbahnen kennzeichnen (Mittelstreifen). Der Wert wird durch das Regelprofil festgelegt und ist auf langen Strecken einheitlich. einerseits sehe ich es gerade bei Autobahnen schwierig an, dort vor Ort genaue Maße zu erheben, und andererseits hast Du diese Breite automatisch, indem Du dem Abstand der highway-ways jeweils die halbe Breite abziehst. Der Sinn könnte darin bestehen, über einen weiteren Wert die Plausibilität der Straßen-tags und -lage zu schätzen, aber da kommt wieder Punkt 1 ins Spiel: die Mittelstreifenbreite kannst Du schwer messen. Unsere Lage der Fahrbahnen der Autobahnen schwankt gegenüber den Luftbildern ständig hin und her, abgesehen von der ungenauen Lage der Luftbilder selbst, die aus GPS-tracks abgeleitet wird, die selbst wiederum eine Unsicherheit von 2-3m im Mittel haben, die Luftbilder die wir haben, werden ziemlich sicher auch in Deutschland irgendwann besser werden, wenn die Ämter das irgendwann mal rausgeben. 2-3 Meter sind m.E. im Autobahnbereich schon sehr gut, wenn wir das überall hinbekämen wäre ich ziemlich zufrieden. zudem soll hier eine imaginäre Mittellinie gezeichnet werden, die es in der Realität gar nicht gibt. damit meinst Du den highway-way. Davon werden wir uns so schnell sicher nicht verabschieden, d.h. den braucht man auf jeden Fall. Das ist die Fahrbahnmitte, die ist zwar nicht markiert, aber geben tut es die natürlich auch in der Realität. Meistens läuft die Linie auf dem Trennungsstreifen zwischen Haupt- und Überholfahrstreifen. Das ist aber weder bei 2 noch bei 3 Spuren die geometrische Mitte, vorausgesetzt, dass die Autobahn eine Standspur hat, die meines Wissens noch gar nicht getaggt wird. Standspuren und Belag ausserhalb der Fahrbahn sorgen zugegebenermaßen für gewisse Unschärfen, aber dem wird sich beim Detailierungswunsch der Mapper sicher auch noch irgendwann jemand annehmen. Ob diese Straßenlinie jetzt in der Mitte des asphaltierten Bereichs (erkennbar in Luftbildern) oder in der der Fahrbahn läuft, spielt kaum eine Rolle, vor allem, solange kein Spurmodell verbreitet ist. Hinzu kommt, dass OSM mit ausschließlich geraden Verbindungslinien arbeitet, die in den real gemappten Kurven der Praxis um bis zu 5m um die Mitte schwanken. m.E. sollte man Kurven so fein es geht annähern, diese eckigen Kurven sehen in der Tat schlecht aus und sorgen auch geringfügig für Lageungenauigkeiten. Du willst also einen Wert, der zwischen 1 und 3 Meter beträgt, aus 2 Messungen ableiten, die im Einzelwert eine Unsicherheit von 3-5m haben, und das Ganze über eine Strecke von mehreren 100km. Mit einer so ermittelten Fläche liegst du um Lichtjahre schlechter als ein über den Daumen gepeiltes Ergbnis, alles andere wäre reines Glück. wieso aus 2 Messungen? Jeder Track ist eine Messung, auf Autobahnen hast Du meistens viele davon. Außerdem ist die Achse in der Realität besser zu erkennen als z.B. jede Gemeindegrenze, ganz zu schweigen von der Fahrbahnmitte. Die Fahrbahnmitte sehe ich bei 2 und 4 Spuren auf der gestrichelten Linie, bei 3 Spuren in der Mitte der mittleren Spur. Finde ich problemlos umzusetzen, während die Achse meistens schlechter zu erkennen ist, sowas hier ist natürlich nochmal ein Sonderfall: http://maps.google.com/maps?hl=dell=42.277158,14.018211spn=0.001046,0.002642t=kz=19 http://maps.google.com/maps?ll=42.011694,13.807771spn=0.002101,0.005284t=kz=18 die Spuren behalten normalerweise ihre Breite, die Mittelachse ändert Ihre Breite öfters mal, sieh mal was hier z.B. los ist (in der Gegend gibts noch mehr krasse Stellen): http://maps.google.com/maps?hl=dell=40.685438,14.761569spn=0.004288,0.010568t=kz=17 Gruß Martin PS: Meiner Meinung nach kann man mit der Relation mehr aussagen, besser rendern und routen und hat weniger Arbeit, aber mir ist es im Prinzip egal wenn Du gerne die Trennflächen als Linien erfassen willst, und man die Tags halbwegs verstehen kann, auch ohne Übersetzen ins Deutsche, dann kann und will ich Dich nicht davon abhalten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Operator bei Bundesstraßen und Autobahnen
Am 1. Juli 2011 07:14 schrieb Christian H. Bruhn br...@arcor.de: Hallo! Es gibt in Deutschland ja einige Streckenabnschnitte von Bundesstraßen (z.B. Herrentunnel in Lübeck) und Autobahnen (z.B. A1 zwischen Hamburg und Bremen) die von privaten Unternehmen betrieben werden. Also kommt an diese Streckenabschnitte ganz klar ein entsprechender Operator. Nun gibt es ja auch die Sammelrelationen für Autobahnen bzw. Bundesstraßen; dort steht aber als Operator 'Bundesrepublik Deutschland' drin. Für die ganze Strecke ist das aber falsch. Wie soll man nun vorgehen? Die Information aus der Relation rausnehmen und alle Streckenabschnitte taggen? Vermutlich wäre es am sinnvollsten, die Autobahn-Sammel-Relationen zu löschen, sofern da kein Mehrwert im Vergleich zu den ref-Tags am Objekt besteht (AFAIK gibt es den nicht). Von daher ist das Taggen der einzelnen Streckenabschnitte mit operator m.E. sinnvoller, da keine Unschärfen und Widersprüche entstehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 4. Juli 2011 15:52 schrieb UMAX974 umax...@googlemail.com: Das hatte ich fast befürchtet, dass jeder seine Sonderwünsche anbringt. Ich denke wir sollten dabei zwei Kriterien einhalten. 1. nicht größer als 4GB besser nur 3-3,5GB, damit man noch Platz auf der SD card für tracks, bzw. POI Daten hat. ich fände eine Version unter 2GB besser, da man alles andere nur auf einem eingeschränkten Kreis von Geräten nutzen kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 4. Juli 2011 16:47 schrieb Boris Wagner b...@gmx.net: Am 04.07.2011 16:18, schrieb M∡rtin Koppenhoefer: 1. nicht größer als 4GB besser nur 3-3,5GB, damit man noch Platz auf der SD card für tracks, bzw. POI Daten hat. ich fände eine Version unter 2GB besser, da man alles andere nur auf einem eingeschränkten Kreis von Geräten nutzen kann. Welche Geräte können denn keine 4GB Kartenfiles lesen? Von eTrex über die 60 bis zu den aktuellen, Dakotas, Oregons, 62er, usw. Können das doch IMHO alle? Auf meinem 60csx gehen (map)Karten über 2GB nicht, wohl aber gehen Micro-SD-Karten bis 4GB (oder evtl. auch mehr). Das Problem ist wohl das (virtuelle/interne) Filesystem des Garmin, welches keine Files über 2GB erlaubt (addressieren kann). AFAIK habe ich die neueste Firmware. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 4. Juli 2011 21:32 schrieb Boris Wagner b...@gmx.net: Am 04.07.2011 16:58, schrieb M∡rtin Koppenhoefer: Beim 60csx gehen mit der aktuellen FW auf jeden Fall Kartenfiles mit 4GB Größe. Da bin ich mir zu 100% sicher. wie? Ich habe die Firmware 4.00 (gem. Garmin Seite die aktuelle) und GPS SW 2.90s. Hängt das evtl. mit dem Gerät zusammen (dass die nicht alle baugleich sind)? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 1. Juli 2011 06:26 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Freitag 01 Juli 2011 01:27:44 schrieb M∡rtin Koppenhoefer: vermutlich hast Du Dir die relation area nicht angesehen, Das ist eine Möglichkeit, die ich aber aus Gründen der Zweckmäßigkeit für ungünstig halte. Bei unserer Erfassungsqualität schwankt diese Area gewaltig in der Breite, während in der Realität der Mittelstreifen über (mindestens) viele Kilometer die gleiche Breite hat., was durch das width-Tag wesentlich besser erfasst wird. das width-tag willst Du wo genau anbringen? Lineare Bauwerke wie Straßen oder Mittelsteifen lassen sich durch die real als Mittelleitplanke vorhandene Achse besser abbilden als durch eine Fläche. bei meinem Modell werden sie weder als Linie noch als Fläche gezeichnet, sondern über tags sowie die Lage zwischen 2 ways indirekt beschrieben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 12:32 schrieb Frederik Ramm frede...@remote.org: hab ich da was verpasst: http://www.openstreetmap.org/browse/way/118720117 highway=axis barrier=beam_barrier visor=hedge oder ist jemand da einfach nur erfindungsreich? Gab es dazu mal ne Diskussion zum Thema Mapping von Autobahn-Mittelstreifen? Dazu gabs m.E. keine Diskussion (muss ja auch nicht unbedingt). Ich finde das Mappen von solchen Dingen durchaus hilfreich, allerdings ist highway=axis m.E. murks und überflüssig (das ist kein highway sondern eine barrier). Für Leitplanken verwende ich persönlich barrier=guard_rail (gibts ca. 273 im planet), beam_barrier bisher erst 75 mal. visor=hedge ist vermutlich Unsinn, ist auch im Wiki nicht dokumentiert und hat erst 42 Vorkommen: http://taginfo.openstreetmap.de:8001/keys/visor#values Vermute dass visor nicht richtige Wort ist, ich stelle mir da eher die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor, ganz sicher bin ich mir allerdings auch nicht. M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch spricht, mal auf tagging nachzufragen, bevor man irgendwelche Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht passen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 13:02 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 30. Juni 2011 12:32 schrieb Frederik Ramm frede...@remote.org: Vermute dass visor nicht richtige Wort ist, ich stelle mir da eher die Klappe einer Ritterrüstung oder das Glas eines Sturzhelms vor, ganz sicher bin ich mir allerdings auch nicht. M.E. kann es nicht schaden, wenn man nicht besonders gut Englisch spricht, mal auf tagging nachzufragen, bevor man irgendwelche Übersetzungen im Wörterbuch sucht, und dann Wörter wählt, die nicht passen. Gegenvorschlag für visor: central_reservation (scheint gem. Wikipedia BE zu sein): http://en.wikipedia.org/wiki/Central_reservation Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 14:19 schrieb Roland Spielhofer rsp...@gmx.net: Am 30/06/2011 13:06, schrieb M∡rtin Koppenhoefer: Gegenvorschlag für visor: central_reservation (scheint gem. Wikipedia BE zu sein): http://en.wikipedia.org/wiki/Central_reservation Im Straßenbau ist Median gebräuchlich und wird auch von vielen Non-English-Natives verwendet. Gem. Wikipedia ist das amerikanisches Englisch. Dazuhin ist das ein sehr vieldeutiges Wort. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 30. Juni 2011 18:40 schrieb Wolfgang wolfg...@ivkasogis.de: Ich halte es für sinnvoll, den Mittelstreifen zu mappen. +1. Nicht dass ich das für erste oder zweite Priorität halte, aber prinzipiell spricht nichts dagegen. Mein eigener Vorschlag (relation, type=area) dazu sieht u.a. vor, das auch implizit zuzulassen, so dass man nicht unnötig Pseudogeometrie eingeben muss, die dann doch keinen Mehrwert bringt (explizit geht mit der Relation natürlich auch, wird man aber eher selten brauchen). Die Begriffe habe ich mir mit Hilfe von Leo rausgesucht. das geht leider oft schief, besser hier oder auf tagging mal nachfragen. Im Straßenbau ist es in D üblich, die Mittellinie der Autobahn als Achse zu bezeichnen, das passt möglicherweise nicht unbedingt im Englischen Sprachbereich. http://www.openstreetmap.org/browse/way/118720117 highway=axis Mittellinie einer mehrspurigen Straße, ich habe kein Problem mit einer Umbenennung hier würde ich doch gerne nochmal nachhaken, weil die Achse einer mehrspurigen Straße haben wir in OSM bereits als way mit highway=* drin. Von daher finde ich highway als key eher ungeschickt, weil man dann schonmal bei nichtmehrbahnigen Straßen die Mittellinie taggen könnte. Auch Achse finde ich nicht so toll, den Begriff gibt es zwar im Straßenbau, er ist aber ggf. abstrakt, d.h. man benutzt die Achse zwar in der Konstruktion und zum Bezug, aber in der Realität findet man gerade bei mehrbahnigen Straßen meist keine Achse vor Ort vor (weil der Mittelstreifen nicht als Linie sondern flächig ausgebildet ist). Dir geht es ja um mehrteilige Straßen, also solchen, die aus mehreren Fahrbahnen bestehen. barrier=beam_barrier Barriere zum Schutz des Gegenverkehrs. beam_barrier = Leitplanke, concrete = Betonbarriere, ... barrier=concrete halte ich für schlecht, weil das ein Material und keinen Typ bezeichnet, wie wärs mit barrier=wall (oder ggf. jersey_barrier, dem spezifischen Ausdruck für die Teile)? Anstatt beam_barrier würde ich guard_rail verwenden. Beides ist hier dokumentiert im Wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types visor=hedge Sichtschutz. scrub halte ich für übertrieben, Knick past auch nicht, am ehesten ist es IMO eine Hecke (diese Grünzeug-Kette, die ab und zu geschitten wird). Hecke ist OK, aber Visier? Ich glaube Du meintest etwas anderes ;-) Da stellt sich jetzt allerdings das übliche Problem bei barrier: welche Ebene taggt man, oder stapelt man? Unten Leitplanke oben Hecke (oft gibts auch unten Mauer, dann Zaun, und ggf. oben noch Stacheldraht). Oder Stützmauer mit Zaun oben drauf, etc. Dafür habe ich bisher auch keine detaillierte Lösung. ps. noch was: bridge=seperated -/- combined (an der Achse) lieber separated ;-) Brückenbauwerke auf Autobahnen werden bisher überhaupt nicht erfasst. Getaggt wird nur da ist Brücke. Ob das jetzt ein Bauwerk ist oder zwei oder mehrere parallel stehen, geht bisher an osm vorbei, zumindest habe ich noch nichts dazu gefunden. dazu gibts allerdings schon Vorschläge (z.B. bridge relation), jedenfalls aus meiner Sicht kein Grund, die Mitte zweier Straßen explizit zu zeichnen. Dieser separated/combined Ansatz würde ja sowieso wieder nur für bestimmte Fälle funktionieren. M.E. ist eine saubere Brücken-Einheit irgendwann an der Zeit, wo man noch viel mehr Zeugs dazutaggen kann, vom Baujahr über den Namen bis zu Details wie Konstruktionstyp, Auflager / Widerlager / Zugverankerungen etc. Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen (analog sonstiger Gebäude), nicht einen Way in der Mitte zweier Straßen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 1. Juli 2011 00:48 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag 30 Juni 2011 19:28:47 schrieb M∡rtin Koppenhoefer: Am 30. Juni 2011 18:40 schrieb Wolfgang wolfg...@ivkasogis.de: Ich halte es für sinnvoll, den Mittelstreifen zu mappen. +1. Nicht dass ich das für erste oder zweite Priorität halte, aber prinzipiell spricht nichts dagegen. Mein eigener Vorschlag (relation, type=area) dazu sieht u.a. vor, das auch implizit zuzulassen, so dass man nicht unnötig Pseudogeometrie eingeben muss, die dann doch keinen Mehrwert bringt (explizit geht mit der Relation natürlich auch, wird man aber eher selten brauchen). Den Mittelstreifen als area zu erfassen, ist sicherlich möglich. In der Realität ist der Mittelstreifen allerdings ein ganz langes, schmales Dings, das mit den Mittelpunktskoordinaten genau genug erfasst werden kann, ggf. unter Zuhilfenahme von width. vermutlich hast Du Dir die relation area nicht angesehen, und zugegebenermaßen könnte man das proposal auch noch besser beschreiben. Die Idee ist, dass man nur die beiden bereits bestehenden highways einfügen würde und über die area-Relation beschreibt man im Normalfall eine virtuelle area wo man über Tags z.B. definiert, aus was sie besteht (hier z.B. Hecke). Optional kann man natürlich für diese Tags auch eine Geometrie zeichnen, aber aus den Straßenbreiten ergibt sich die Breite des Mittelstreifens meist von selbst. Man definiert so gleichzeitig auch eine lineare Übergangsmöglichkeit z.B. für Fußgänger (bzw. an der Autobahn würde man foot=no setzen, da verboten). Auch Achse finde ich nicht so toll, den Begriff gibt es zwar im Straßenbau, er ist aber ggf. abstrakt, d.h. man benutzt die Achse zwar in der Konstruktion und zum Bezug, aber in der Realität findet man gerade bei mehrbahnigen Straßen meist keine Achse vor Ort vor (weil der Mittelstreifen nicht als Linie sondern flächig ausgebildet ist). Ja, aber die Straße als Ganzes incl. aller Fahrsteifen, Standspur, Bankett, Graben, Böschung etc hängt ausschließlich an dieser Achse. bei der Konstruktion / Herstellung vielleicht. In der realen Welt sieht man sie nicht. Sie ist ein theoretisches / vermessungstechnisches Konstrukt. barrier=concrete halte ich für schlecht, weil das ein Material und keinen Typ bezeichnet, wie wärs mit barrier=wall -1, gibt es schon als Wände, beispielsweise an Tunnelbauwerken. das ist auch nichts anderes als eine Wand, daher ja der Vorschlag. Mit entsprechender Höhe ist es klar definiert. visor != visier visor = Blendschutz, Nr.1 bei Leio Dir ist schon klar, dass Blendschutz z.B. auch eine Sonnenbrille ist? aber schlage gerne was passenderes vor. s.o. im Thread dazu gibts allerdings schon Vorschläge (z.B. bridge relation), jedenfalls aus meiner Sicht kein Grund, die Mitte zweier Straßen explizit zu zeichnen. Zeichnen verlangt niemand. Nur die Angabe der Mitte einer Straße mit mehreren Fahrbahnen. Welcher Renderer das für welchen Maßstab nutzt, ist eine ganz andere Sache. mit zeichnen meine ich, dass man einen expliziten Way mit expliziten Nodes einträgt, wie Du das getan hast. Dazu würde ich einen umschliessenden Way (Grundriss) haben wollen (analog sonstiger Gebäude), nicht einen Way in der Mitte zweier Straßen. Sofort einverstanden. Aber bis das für alle Bauwerke weltweit gemappt ist, halte ich es für sinnvoll, dem Renderer für große Maßstäbe schon mal eine Möglichkeit des näherunsweise korrekten Zeichnens zu geben. ja, aber bitte nicht so. Lasst es uns gleich so machen, dass es auch weiterverwendbar ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] prüfen von Relationsvollständigkeiten
Am 29. Juni 2011 09:01 schrieb André Joost andre+jo...@nurfuerspam.de: Am 29.06.11 08:40, schrieb Hermann Peifer: Bei manchen Fahrrad-Routen, die ich gerade aufnehme koennte man locker auf 100% der ausgewiesenen Laenge kommen, weil die Route teilweise beidseitig von secondary (u.ae.) highways verlaeuft, z.B. http://osm.org/go/0NWjZsM0?relation=29135 ja, irgendwo hat alles seine Grenzen. +1 Sobald man Plätze hinzufügt, stimmt die Länge auch nicht mehr. oder man teilt den Platz (dann ist der Unterschied zwischen Teilstück des Perimeters und mittig über den Platz praktisch zu vernachlässigen), was für den highway-area-Teil dann eine Relation erfordert. Ich zeichne deshalb auch immer nur eine Fahrtrichtung ein, und überlasse es dem Nutzer, die STVO-konforme Fahrbahnteilfläche zu nutzen. Wenn man sehr penibel ist kann man auch ähnlich den Bus-Relationen eine Hin- und eine Rückrichtung machen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed
2011/6/28 André Joost andre+jo...@nurfuerspam.de: Am 27.06.11 20:22, schrieb malenki: proposed != construction Leider steht im aktuellen Mapnik-Stil: Rule maxscale_zoom12; minscale_zoom12; Filter([highway] = 'proposed' or [highway]='construction') and ([construction]='motorway' or [construction]='motorway_link')/Filter -- http://trac.openstreetmap.org Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Wege auf Asphaltflächen erstellen?
Am 28. Juni 2011 09:07 schrieb Chris66 chris66...@gmx.de: Ok, laut Wiki dürfen mit pedestrian auch Plätze getaggt werden, die keine echten (Zeichen 242) Fussgängerzonen sind. highway=pedestrian ist eine Straße, die von Ausnahmen (z.B. Lieferung) abgesehen für Fußgänger ist. Mit area=yes wird es zur Fußgängerfläche (ggf. kann man bicycle=yes und anderes ergänzen, je nachdem, wie es vor Ort geregelt ist). Zonen gibt es bisher meines Wissens in OSM nicht, und ich sehe auch nicht, wozu man das brauchen sollte. Eine Zone ist ein Gebiet aus mehreren pedestrians und ergibt sich von selbst. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern und Zufahrt
Am 28. Juni 2011 19:45 schrieb fly lowfligh...@googlemail.com: Wenn das nur private Zufahrten sind (highway=service): und service=driveway und access=private/permissive/(destination) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] nudism=designated
Am 29. Juni 2011 00:25 schrieb Stephan Wolff s.wo...@web.de: http://www.openstreetmap.org/browse/node/287134792 Das ist ein node mit 3 tags: besser als ein Node wäre eine area Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kartendaten für Tansania
Am 27. Juni 2011 10:06 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Tom Müller tomsmuel...@gmx.net wrote: für ein Projekt der Ingenieure ohne Grenzen suche wir Kartendaten in Tansania (-1.525, 31.000 bis -1.650, 31.2000). Leider sind alle in JOSM anzeigbaren Sat-Bilder in dem Gebiet gänzlich unbrauchbar. Hat evtl. jemand noch eine Idee, wie man an vernünftige Kartendaten des Gebiets (egal ob Bilder oder fertige Daten) herankommen kann? Es gab mal dieses Tracks4Africa Projekt irgendwie so ne Art OSM Mitbewerber. Es gibt auch bei der FAO (Welternährungsorganisation der UNO) Karten von Afrika. Allerdings sind die nicht unbedingt super (landuse z.B. sehr grob aufgelöst). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed
Am 27. Juni 2011 09:52 schrieb Stephan Wolff s.wo...@web.de: Am 26.06.2011 23:17, schrieb Josias Polchau: Ich halte ein Ticketsystem zum Anpassen des Mapnik-Stils für ungeeignet. Echte, technische Fehler betreffen vermutlich auch den Mapnik-Stil auf osm.org und sollten dort gelöst werden. kann man so nicht sagen. Sobald man den Stil ändert, kann im Prinzip alles passieren. Mittlerweile sind die beiden Stile schon ziemlich verschieden, weil der dt. Stil bisher nicht fortgeschrieben wurde. Es geht aber auch nicht in erster Linie um technische Fehler, sondern z.B. auch um so Dinge wie die Layerreihenfolge. Da macht man immer einen Kompromiss, aber m.E. wäre es interessant, auf dem dt. Stil einen anderen Kompromiss zu machen wie im englischen. Einfach eine Kopie des engl. Stils mit anderen Farben ist doch langweilig. Vermutlich würden viele Fehlermeldungen kommen, dass ein Tag für ein Spezialinteresse nicht dargestellt wird. Setzt man die Tickets der Reihe nach um, ist die Karte am Ende sehr unübersichtlich man wird sicher nicht alles umsetzen, sonst könnte man es ja gleich wie T@H machen und jedem Schreibzugriff gewähren... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed
Am 27. Juni 2011 12:21 schrieb Frederik Ramm frede...@remote.org: Also weniger wir probieren hier mal was neues aus als vielleicht eher ok, in England sind Pubs wichtiger als Restaurants und erscheinen daher einen Zoomlevel frueher, aber bei uns ist das eigentlich kulturell nicht so, daher machen wir das anders. Ich habe gerade fast dasselbe an Josias und Sven geschrieben (Pubs weniger prominent), da muss was dran sein ;-) Wobei diese Prorisierung natürlich immer vom persönlichen Lebensstil abhängt und auch der Deutsche nicht unbedingt ein Kneipenmuffel ist. M.E. sollte man zu einem gewissen Grad (d.h. dass immer noch eine ansprechende und vielseitig verwendbare Karte entstehen muss) durchaus auch mal was neues ausprobieren, so dass sich die beiden Stile ergänzen. Türme und Burgen/Schlösser würde ich z.B. gern in der Karte sehen, manche Flächen anders behandeln (da hat sich allerdings in letzter Zeit erfreulicherweise auch einiges am engl. Stil getan), für U-Bahnhöfe andere Icons als für Bahnhöfe, etc. Zu letzterem eine Frage an alle: macht es wirklich Sinn, beides als railway=station zu taggen und nur über die Schienenart den Unterschied festzulegen? Man kann das zwar in Postgres lösen, aber ich glaube dass es rechenintensiv ist (zumindest bei den Regeln, die ich dafür mal gemacht habe, und die auch Stationen die als Polygon gemappt sind berücksichtigen, also wo die station nicht node der Schiene ist). Hat jemand dafür eine schicke Lösung? Am einfachsten ist sicher, ein railway=subway_station einzuführen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutscher Mapnik-Stil ohne highway=proposed
Am 27. Juni 2011 17:29 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Sollten nicht eher diejenigen ein Spezialoverlay erstellen, die die Daten sehen wollen und nicht diejenigen, die es nicht sehen wollen? Klar sollte das. Schon weil man mit einem Overlay erheblich leichter Daten einfügen als überpinseln kann. ja, am besten wir liefern weisse tiles aus, dann kann jeder das überblenden, was er haben will ;-) Wenn wirklich jemand unbedingt die geplanten Trassen auf openstreetmap.de haben muss, dann kann ich mich gerne daran versuchen, da einen passenden OpenLayers-Layer für zu basteln. Wäre das fest auf die Tiles gerendert, taugen diese nicht mehr für das Anzeigen einer Karte ohne diese Elemente. Overlays sorgen leider auch für viele Probleme: verdeckte Elemente/ Beschriftungen, schlechteres Antialiasing, Erhöhung des Speicherbedarfs und der Downloadzeit (overhead), ... Nicht dass ich falsch verstanden werde: geplante Straßen müssen m.E. nicht unbedingt sein, aber grundsätzlich sind Overlays keine gleichwertige Lösung zu einem dedizierten Stil. Spezialoverlays sind halt ein schwammiger Begriff: für den einen gehören z.B. geplante Autobahnen zum Standardset einer Straßenkarte, für andere ist das Spezialzeugs. Auf eine gemeinsame Linie werden wir hier vermutlich nie kommen, d.h. ganz jedem kann man es nicht Recht machen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ebook-Karte auf Kindle
Am 27. Juni 2011 13:51 schrieb Barthwo wolfg...@barthwo.de: Das oben erwähnte Garmin GPSmap 60 kenne ich nicht, aber vielleicht ist das Verhalten bei Sonnenlicht bei dem ja besser als bei dem IBEX. wenn Deine Beschreibung des IBEX zutrifft dann ist das Garmin 60 um Längen besser: ich hatte noch nie Probleme bei Sonnenlicht, im Gegenteil ist es da sogar besser ablesbar. Leider gibt es nichts Vergleichbares mehr von Garmin mit schnellerem Chip (das 62 ist ziemliche Grütze m.E. und Touchscreen will ich auch nicht bei einem GPS) (Bedienung mit Handschuhen, blind, Schutz vor versehentlicher Bedienung, etc.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder für JOSM
Am 27. Juni 2011 15:42 schrieb Steffen Heinz eifelhu...@gmx.de: Am 27.06.2011 15:21, schrieb fly: funktionier nicht an allen Stellen :( dann muss das Gebiet Abfotografiert werden (mit einem entsprechenden Tool) dann und nur dann kann es verkleinert werden, gedreht verzerrrt usw (gerade in meinem Gebiet ist das bei ca 50% der Satellitenbilder erforderlich) m.E. kann man die Bilder mal ein bisschen rumschieben und hoffen, dass sie dann besser passen, aber drehen und verkleinern/vergrößern, stauchen und ähnliches halte ich nicht für sinnvoll. Das wird nie ganz stimmen. Wenn die Bilder schlecht weiterverarbeitet wurden, dann sind die Fehler die aus dieser Verarbeitung stammen, jetzt fest in den Fotos drin. Entweder man schätzt sie noch für brauchbar ein, oder man sucht sich bessere ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
