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] 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
Re: [Talk-de] Wie Wege auf Asphaltflächen erstellen?
Am 27. Juni 2011 19:37 schrieb Jan Torben Heuer m...@jtheuer.de: Ich würde gerne die Flächen um routingfähige Wege erweitern, weis aber nicht wie. Es müssten ja quasi für den Renderer unsichtbare Wege sein die dann aber doch von OSM-Routing engines verstanden werden als Wege. Im moment sieht das Routingergebnis so aus: http://derp.co.uk/37b0b.info Ich würde statt die eingehenden Wege mit der Asphaltfläche zu connected lieber auf den Asphalt mittig einen Weg legen. Jemand eine Idee wie ich das dann korrekt Taggen müste? ein weiterer mittiger Weg ist überflüssig. M.E. ist das tagging mit highway=footway für diese Flächen nicht ganz optimal, würde pedestrian vorschlagen. Wenn die Flächen an allen Stellen wo sie auf Wege treffen mit denen verbunden sind, dann wird mit normalen Routern jetzt schon damit geroutet (allerdings an den Kanten entlang und nicht in der Mitte), d.h. da muss man eigentlich nichts mehr dran machen. Wie Peter auch schrieb: da müsste am Router gearbeitet werden, nicht an der Karte. 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 27. Juni 2011 20:51 schrieb Chris66 chris66...@gmx.de: Am 27.06.2011 20:18, schrieb M∡rtin Koppenhoefer: ein weiterer mittiger Weg ist überflüssig. M.E. ist das tagging mit highway=footway für diese Flächen nicht ganz optimal, würde pedestrian vorschlagen. -1 Es sei denn die Flächen sind als echte Fussgängerzone ausgeschildert. wieso? M.E. ist ein footway was kleines, die Startbahn auf einem Verkehrsflughafen als footway auszuzeichnen oder footway für Flächen zu verwenden finde ich seltsam. Im Endeffekt ergibt sich die Größe allerdings aus der Größe ;-) 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 26. Juni 2011 11:12 schrieb Matthias Julius li...@julius-net.net: Die meisten Pixel wurden ja nicht genau senkrecht von oben fotografiert, sondern schräg. Das sieht man sehr schön an hohen Gebäuden, Schornsteinen oder ähnlichem. Dort deckt sich auf den Luftbildern das Dach meist nicht mit dem Grundriss. Da muss man eben aufpassen, dass man den Grundriss mappt und nicht das Dach. Dazu gibt es hier gut bebilderte Erläuterungen von Marek Strassenburg-Kleciak: http://wiki.openstreetmap.org/wiki/DE:Roof_modelling Ein Tutorial für absolute Anfänger könnte auch nur ein paar weniger Bilder daraus verwenden und erläutern (und auf die längere Seite zur Vertiefung verweisen), z.B. http://wiki.openstreetmap.org/w/images/thumb/3/3d/Potlatch_2_-_Rysowanie_budynk%C3%B3w_03.jpg/400px-Potlatch_2_-_Rysowanie_budynk%C3%B3w_03.jpg 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 26. Juni 2011 13:06 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Garry wrote: Im Vordergrund sollte doch die Information für die Allgemeinheit und nicht die Desinformation für das Ziel eines Vereins stehen... So hat jeder andere Ziele. Nur bringt es OSM wirklich etwas, wenn Institutionen bewusst auf das Nutzen der OSM-Karte verzichten, weil ein in der Region für Unmut sorgender Trassenverlauf dort sichtbar ist? Da bin ich allerdings bei Garry: wir sollten uns nicht selbst zensieren weil evtl. irgendwo sich irgendwer von der Realität auf den Schlips getreten fühlt. Und eine reale Planung ist Realität. Solange das als Planung und nicht als Straße oder Baustelle auftaucht, kann Information bei der Auseinandersetzung mit dem Thema nur helfen. Wenn Wege eingezeichnet sind, die aktuell noch diskutiert werden und der Trassenverlauf keineswegs sicher ist, dann wäre z.B. ein deutliches Anheben der Transparenz eine Option. Aktuell wird alles, was geplant ist, eher auffälliger gerendert, als eigentliche (physisch vorhandene) Straßen oder Feldwege. Das sind Details, die man bei entsprechender Datenlage natürlich auch im Rendering berücksichtigen kann. Wie ist Dein Vorschlag, um die Wahrscheinlichkeit dass eine Planung realisiert wird, bzw. um den Planungsstand in OSM-Tags umzusetzen? Oder gibt es da schon was im Wiki? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmäler in Bayern innerhalb bestimmtem Rechteck in OSM anzeigen?
Am 26. Juni 2011 13:09 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Andere Dinge in der Denkmalliste liegen laut deren Karte in Mitten von Feldern. Da wurde schon jahrzehntelang drübergepflügt sodass man von den angeblichen Denkmälern nichts mehr sieht. Zum einen sind Denkmäler in der Denkmalliste nie angebliche sondern immer reale Denkmäler, und zum anderen sind Bodendenkmäler nicht unbedingt von aussen sichtbar. Je nach Tiefe macht es ggf. auch nichts aus, wenn da jahrzehntelang drübergepflügt wird. Natürlich darf man nicht über einem Denkmal pflügen, das sich in einer Schicht befindet, die beim Pflügen berührt wird. Wenn Du da Fälle kennst kannst Du die in unser aller Interesse zur Anzeige bringen. 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 26. Juni 2011 16:18 schrieb Henning Scholland o...@aighes.de: Hallo Meiner Meinung nach hat das nichts mit Selbstzensur zutun. Bei Autoatlanten und ähnlichem mag es durchaus gerechtfertigt sein, dass dort geplante Trassen eingezeichnet werden. Diese Wälzer haben bei vielen Autofahrern durchaus Lebenszeiten von 10 Jahren. Sollte der deutsche Mapnik-Stil eine Straßenkarte darstellen wollen, wovon ich bisher ausging, dann frage ich mich, ob es auf einer Karte, die sehr häufig aktualisiert wird, überhaupt sinnvoll ist, diese Infos darzustellen, wo doch der eigentliche Zweck der ist, real existierende Wege/Objekte darzustellen. M.E. geht der dt. Mapnik-stil über eine Straßenkarte hinaus. Wie auch beim internationalen Stil geht es darum, beispielhaft zu zeigen, was man mit OSM machen kann, aber auch, einen Überblick zu geben, welche Standard-Daten es wo schon gibt, wo die Daten dichter und wo dünner sind, etc.. Ob da jetzt die paar geplanten Straßen dargestellt werden oder nicht, ist mir im Prinzip egal, aber ich widerspreche gern dem Argument, bestimmte Dinge seien entgegen dem Sinn der Karte. Erst recht finde ich Aussagen provozierend, wo Leute schreiben: Wenn dies und das dargestellt wird, dann nutzen wir die Karte nicht mehr. Man kann es in einer Karte sowieso nicht allen Recht machen, Demokratie funktioniert in Gestaltungsfragen auch eher schlecht, und ist zum Glück bei OSM auch nicht nötig: wenn man bestimmte Dinge in der Karte nicht sehen will, dann kann man das schnell ändern (Stil clonen und die Sache rausnehmen). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM: Kein Zoomlevel 19 :(
Am 26. Juni 2011 19:37 schrieb Martin Trautmann tr...@gmx.de: Ok, dennoch erklärt das nicht, warum der Osmarender-Zoomlevel 17 dem gleichen Maßstab von Mapnik 18 entspricht. Wie kommst Du da drauf? Bei mir geht's sprich Osmarender z17 entspricht Mapnik z17. Mapnik tanzt da aus der Reihe im Vergleich zu den anderen drei Angeboten - und zwei der drei anderen schaffen noch eine Stufe mehr, nur Osmarender nicht. Die könnten das alle bis z27 schaffen wenn Rechenleistung und Speicherplatz zur Verfügung stünden. 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 26. Juni 2011 21:36 schrieb Simon Poole si...@poole.ch: Leider steht nirgends ob distance die Soll- oder Istlänge ist. Und man kann lange darüber philosophieren welches überhaupt sinnvoll wäre m.E. macht nur die Soll-länge Sinn, die Istlänge ist ja schon automatisch da (Zumindest wenn man eine lat-long-DB hat kann man das dort ohne Probleme rauslesen). Die Soll-länge wäre das, was jemand der die Route geprüft hat, beim Zeitpunkt der Prüfung ermittelt, oder? Oder geht es darum, das von Wegweisern zu übernehmen? 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 26. Juni 2011 21:21 schrieb Jan Tappenbeck o...@tappenbeck.net: ich weiß nachfolgende Frage nicht ein 100% Ergebnis für die Vollständigkeit ist - aber diese könnte ein Index für einen gewissen Grad sein. ist das eine Google-übersetzung oder hast Du das selbst so geschrieben? ;-) Es gibt doch diese Relationsprüfungen geht es um Routen? - wenn in den Relationen nun ein tag distance vorhanden ist, dann könnte man diese Werte doch einander gegenüberstellen und vergleichen. So könnte ein grober Test für die allgemeine Nutzung entstehen der vielleicht irgendwo (auch im Wiki) einfließen könnte. wenn ich Deinen Beitrag richtig interpretiert habe, dann geht es darum, die Vollständigkeit von Routen zu prüfen bzw. deren Länge zu ermitteln, um sie von Zeit zu Zeit wieder zu überprüfen, ob sie noch intakt sind? Finde ich nicht schlecht, wobei dann distance (Abstand) eher nicht so geeignet erscheint, wie wäre es mit length? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Shop nicht in Mapnik zu sehen / Unsichtbare Dinge
Am 26. Juni 2011 23:03 schrieb hansdorfff h...@taponet.de: ich habe einen Shop als Node in die Karte eingebaut, wobei ich mir immer nicht sicher bin, ob Shops in der Karte stehen sollten [und wenn nicht, warum stehen dann Kneipen drin und werden gern auch angezeigt? :)] Na, wie auch immer, jedenfalls zeigt Mapnik meinen Node mit shop=toys, name=Fantasy Game Shop und website=http://...bla..; nicht an: http://www.openstreetmap.org/browse/node/1335415522 ja, weder Mapnik noch Osmarender stellen derzeit Spielwarenläden dar. Andere Läden werden z.T. dargestellt. Natürlich kann jeder Kartenanbieter selber entscheiden, was er rendert. Besser fände ich es allerdings auf www.openstreetmap.org, wenn man die Entscheidung, was zu sehen ist, in einem gewissen Rahmen dem Website-User überlassen würde. Das könnte unterschiedliche Dinge betreffen: Ansicht von Gebäuden an/aus, Ansicht geplanter Straßen an/aus, Ansicht von Höhenlinien an/aus, Schummerung an/aus, Ansicht von xyz an/aus. Das gibt es bei verschiedenen auf OSM basierenden Karten, wobei die Umsetzung entweder verschiedene vorberechnete Layer oder dynamische Overlays benötigt. Beides ist glaub für die Hauptseite und weltweit für OSM zu Ressourcen-intensiv, aber zugegebenermaßen wäre es nett. Z.B. wünschen sich auch viele eine Beschriftung in lokaler Sprache, etc. Höhenlinien und Schummerung sind in jedem Fall Dinge, die sich mit OSM nicht realisieren lassen (wir sammeln keine Höhendaten, zumindest nicht systematisch und flächendeckend), so dass man dazu eigentlich immer auf externe Daten zurückgreifen muss (z.B. SRTM). Das ist neben den Rechnerressourcen und Entwicklerkapazitäten halt auch eine Frage des Projekt-Fokus. Wieso sollte OSM Bandbreite für fremde Daten wie Höhendaten verbrauchen? Das Ziel der Karten auf OSM ist vor allem, das Projekt zu präsentieren. Wenn man z.B. Schummerung in die Tiles einbaut, muss man schnell ein Mehrfaches an Daten übertragen. 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 26. Juni 2011 23:17 schrieb Josias Polchau sp...@youseeus.de: Am 24.06.2011 02:21, schrieb Frederik Ramm: So, wie es im Moment ist, gibt es allerdings niemandem, bei dem man einen Mangel melden koennte und der sich dann darum kuemmert. wenn ich zeit hätte (ich bastele grad noch an dem Fußwegrouting), würd ich das gerne machen, weil mich das brennend interessiert. Was fehlt ist ein Art Ticketsystem. +1, eine Rubrik im trac von osm.org ist vermutlich machbar. Für den Stil auf osm.de könnte man dort ja auch auf deutsch Einträge machen. Ich würd mich zumindest an der Betreuung dieser beteiligen und ab und Änderungen einpflegen. cool, dann sind wir schon mind. 2 (Sven Geggus wollte da evtl. auch mithelfen), ich bin auch bereit, am deutschen Mapnik-Stil mitzuarbeiten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäudeteile
Am 25. Juni 2011 10:11 schrieb Walter Nordmann walter.nordm...@web.de: M∡rtin Koppenhoefer wrote: das Problem ist halt, dass Du haufenweise sich überlappende Flächen haben wirst (weil Gebäudeteile übereinandergestapelt sind), aber es stimmt, man kann die auch einfach übereinander rendern und sich da gar nicht weiter drum kümmern. OSM ist nicht nur zum Kartenmalen = Rendern da. Nicht alles, was man am Ende auf dem Papier sieht, stellt die Wirklichkeit richtig dar - es erscheint nur so. Berechnet bitte mal die Fläche oder den Umfang eines solchen Konstruktes. den Umfang von verschiedenen Gebäudeteilen zu berechnen halte ich für Unsinn, das ist mehr oder weniger willkürlich, je nachdem wie der Mapper die Gebäude aufgeteilt hat und interessiert auch nicht. Evtl. interessiert die Fläche, die insgesamt überbaut ist, dann kann man ja so vorgehen wie oben beschrieben (ST_UNION oder so, hab den Befehl nicht im Kopf aber es gibt z.B. in Postgres was dafür), wobei man bei auskragenden Konstruktionen (wenn das Gebäude oben breiter ist als dort wo es auf dem Boden lastet) komplexere Analysen machen müsste. Multipolygon ist jedenfalls wenig geeignet, weil es sich auf Flächen bezieht, man bei Gebäuden aber Volumen betrachten muss. Hier ging es allerdings um Rendern, wo eine einfache Betrachtungsweise ausreicht. Klar, wenn man 3D-Modelle ableiten will oder an anderen Arten der Analyse interessiert ist muss man sich mehr einfallen lassen, als einfach alles wie es aus der DB kommt als unabhängiges eigenständiges Gebäude(-teil) zu sehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] land_use aneinanderkleben?
Am 25. Juni 2011 12:27 schrieb Frederik Ramm frede...@remote.org: Wenn zwei Flaechen wirklich nahtlos ineinander uebergehen, wuerde ich sie auch zusammenkleben; ist die gemeinsame Grenze jedoch laenger als eine Handvoll Nodes, wuerde ich da mit Multipolygonen arbeiten. Das ist eigentlich wenig umstritten. +1 Wenn an der Grenze zwischen den beiden Flaechen ein Zaun oder ein Weg verlaeft, waehlen viele Mapper lieber zwei separate Flaechen mit einer ebenfalls separaten Linie dazwischen. ein Zaun und ein Weg sind m.E. fundamental verschieden. Bei einem Zaun kleben m.E. die Flächen i.d.R. aneinander (falls es nicht noch andere kleinere Abstandsflächen am Zaun gibt), bei einem Weg nicht. Es gibt aber auch Leute, die selbst dann nur eine gemeinsame Grenzlinie zeichnen, die dann dreierlei auf einmal ist - Grenze des Waldes, Grenze der Wiese, und Zaun oder Strasse. In dieser Sache gibt es keinen Konsens. Im Prinzip sollte die zuerst genannte Betrachtungsweise für alle Fälle ausreichen, um den gewünschten Endzustand zu beschreiben: wenn 2 Flächen direkt aneinandergrenzen sollten sie das auch in OSM tun, wenn noch irgendwas dazwischen ist, sollte in OSM da auch mind. eine Lücke sein (oder besser eben das beschrieben werden, was dazwischen ist). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie 1. Hilfe Box mappen
Am 25. Juni 2011 12:29 schrieb Colin Marquardt cmarq...@googlemail.com: Am 24. Juni 2011 22:23 schrieb Andreas Tille andr...@an3as.eu: ich habe einen am Baum montierten Kasten mit 1. Hilfe Verbandszeug mit der Aufschrift: Selbsthilfe-Box; Bergwacht Harz gefunden. Dazu finde ich kein passendes Tag. Was verwendet man hier am besten? Ich benutze (und rendere auf hikebikemap.de) amenity=rescue_box. http://taginfo.openstreetmap.org/search?q=amenity%3Drescue_box#tags hat 23 Verwendungen und wird im Wiki definiert: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drescue_box M.E. wäre das thematisch unter emergency ganz gut aufgehoben. Rescue box habe ich auf englisch noch nie gehört, hätte da eher so was wie first aid kit oder so erwartet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäudeteile
Am 25. Juni 2011 12:44 schrieb Walter Nordmann walter.nordm...@web.de: Weil mal ehrlich: Wenn es eine Methode gibt, die schnell in Renderern unterstützt werden kann, und eine andere, mit der man weniger Aufwand bei der Berechnung des Gebäudeumfangs hätte - welche wird sich wohl durchsetzen? Die, die ich kenne, wird bereits seit langem - ohne dass euch das wohl klar ist- von den gängigen Renderen unterstützt. Aber schon wieder darauf hinzuweisen, hab ich langsam keine Lust mehr. Einmal pro Thread reicht dafür aus. Könntest Du bitte etwas expliziter werden? Aus dem von Dir hier geposteten Link werde ich nicht schlau (was meinst Du da?) und welches ist die Methode, die von den gängigen Renderern unterstützt wird? Könntest Du mal ein Beispiel posten, am besten nicht als Ausschnitt sondern direkt die URL eines Objekts? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmäler in Bayern innerhalb bestimmtem Rechteck in OSM anzeigen?
Am 24. Juni 2011 10:49 schrieb Stephan Knauss o...@stephans-server.de: Du kennst die Nutzungshinweise? Das ist mit Openstreetmap erst mal nicht kompatibel. nett, dass Du drauf hinweist, aber er schrieb ja: für den privaten Gebrauch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
