Re: [Talk-de] How to map a....
Am 10.12.2013 um 22:12 schrieb Willi Rehfeld electricwarr...@web.de: hier ist es eine leerstehende Schule, die nun als Unterkunft für Asylbewerber genutzt werden soll. M.E. wäre social_facility dafür ein Euphemismus. Besser ein eigener tag, von dieser Art Einrichtungen gibt es ja einige. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Viehunterstand?
Am 19.11.2013 um 20:13 schrieb NopMap ekkeh...@gmx.de: Die alten Shelter unterscheiden sich bereits deutlich voneinander, Grillpavillion, Picknickplatz oder Schutzhütte machen einen großen Unterschied. Von daher ist es jetzt schon nötig, für eine sinnvolle Auswertung den Typ zu berücksichtigen. Wenn es Dir egal ist ob es eine Berghütte oder ein Bushäuschen ist und es Dir nur um ein Dach geht, dann ist Dir auch mit einem solchen Unterstand gedient. +1, in ländlichen Gebieten ist es normal, sich bei plötzlichem Regen auch unter einen Viehunterstand zu flüchten, shelter ist das auf jeden Fall. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 05.11.2013 um 21:06 schrieb Garry garr...@gmx.de: Residential dürften da ehr die Ausnahme sein, die durchgehenden Straßen sind mindestens unclassified und die Nebenstraßen ehr tracks. Wenn da Leute wohnen die keine Bauern sind, dann ist es kein Track und wenn das keine Verbindungsstraßen sind, dann sind sie auch keine unclassifieds Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 05.11.2013 um 23:18 schrieb Garry garr...@gmx.de: Wo gibt es so etwas in nenneswertem Ausmass? Siehst Du ein Problem wenn Anwendungen(!) residentials per default als innerorts interpretieren wenn (noch) nicht anderst angegeben? Im Ausland und ggf. in den neueren Bundesländern (Bestandsschutz), in den älteren Bundesländern ist der Landschaftszersiedelung schon ziemlich lange durch BauGB 35 (Bauen im Aussenbereich) ein Riegel vorgeschoben, das stimmt zwar, aber die Welt ist ja noch ein bisschen größer ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 04.11.2013 um 21:23 schrieb Bernhard Weiskopf bweisk...@gmx.de: Das 50er-Schild gilt übrigens für alle Fahrzeuge, das Ortsschild dagegen nur für Kraftfahrzeuge. Radfahrer dürfen nach letzterem also schneller fahren. Jein, sie müssen ihre Geschwindigkeit anpassen. Dürfte für die allermeisten aber sowieso keine Rolle spielen Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 04.11.2013 um 20:54 schrieb Garry garr...@gmx.de: Eine Ansammlung von residentials (ein tag!) lässt darauf schließen dass diese Innerorts sind. Aus ehr sporadisch gesetzten, verletzlichen Ortsschildern - insbesondere ohne weitere Angaben - wird es schwierig die Situation korrekt abzubilden. so ein Ortsschildnode ist nicht so verletzlich, klar, wenn er gelöscht ist ist er weg, aber normalerweise wird so ein freier Node nicht so viel verschoben. Residentials kannst Du hierzulande viele finden, die außerhalb geschlossener Siedlungen verlaufen. In welchem Zusammenhang? Straßen, die ein gefahrloses, schnelleres Fahren als innerorts zulassen würde ich in der Regel nicht als residential klassifizieren. Das tun sie nicht. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] innerorts oder außerorts - WAS: Datenmodell für straßenbegleitende Wege
Am 04.11.2013 um 14:54 schrieb Ronnie Soak chaoschaos0...@googlemail.com: Allerdings kann damit wie schon beschrieben ein Router nicht bestimmen, wo man sich befindet. Wieso machst Du das dann trotzdem so? Ich finde diese Schilder-Nummern-Nummer ein bisschen übertrieben, und auch gibt es nicht in allen Ländern Nummern, von daher finde ich bei so eindeutigen Dingen wie einem Ortsschild einen sprechenden Tag besser und international verwendbar. Er weiß weder, ob der Startpunkt innen oder außen lag, noch kann er die angesprochenen Inseln bilden, solange Fälle wie Ortsausgang-ist-Ortseingang Kein Problem m.E., sind ja verschiedene Orte, man muss dann dort allerdings 2 nodes machen, auf jeder Seite einen, mit dem jeweiligen Namen. und fehlende Schilder existieren. Generell wäre es ein ziemliche Aufwand. Ja, dann doch lieber Polygone oder jeden einzelnen Highway taggen, das ist sicher weniger Aufwand als ein paar Nodes. ;-) Auf implizite Geschwindigkeitsbeschränkungen verlasse ich mich allerdings sowieso nicht, die tagge ich an alle Wege explizit, unabhängig von inner- und außerorts. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] path am Strand fuer den Router ...
Am 04.11.2013 um 20:16 schrieb Frederik Ramm frede...@remote.org: Bei Plaetzen ist das anders; die wenigsten Mapper wuerden per Multipolygon ein Loch in den Strand schneiden, wenn da eine Huette vom Bootsverleih steht, oder ein Loch in den Marktplatz, bloss weil in der Mitte irgendeine Reiterskulptur auf einem Podest steht. Eigentlich ist das noch vertrackter, habe da bisher noch keine wirklich zufriedenstellende Lösung entwickelt. Die Reiterstatue IST ja Teil des Platzes (mit Namen Foo, etc.) allerdings nicht Teil der Fläche highway=pedestrian, area=yes, surface=* etc., wobei diese begehbare Fläche schon auch den Namen trägt und in osm haben sollte. Wenn da jemand eine gute Idee hat, wie man das konzeptionell am Besten darstellen kann... Vermutlich sollte man doch den Platz von der Fußgängerverkehrsfläche entkoppeln. Gruß, Martin PS: am Rande erwähnt sei, dass sie meisten derzeitigen Routingprogramme highways ignorieren, die in einer Multipolygonrelation getaggt sind. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing-Hinweise taggen
Am 01.11.2013 um 15:18 schrieb Alexander Heinlein alexander.heinl...@web.de: On Fri, Nov 01, 2013 at 03:01:01PM +0100, Thorsten Nau wrote: ich denke mal, dass das Problem darin besteht, dass die Auf- und Abfahrten (trunk_link) mit motorway=yes getagged sind. Für die Straße an sich, ist das sicherlich korrekt. Aber die Auf- und Abfahrten sollten aus meiner Sicht kein motorway=yes bekommen. motorroad=yes meinst du sicher :) Ob an die Zubringer das motorroad üblicherweise gesetzt wird oder nicht, weiß ich nicht. Dort, wo das Kraftfahrstraßenschild steht, den way aufsplitten, und dahinter gilt dann das motorroad=yes tag, unabhängig von der Auffahrtsfrage. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezialgebiet Fahrrad-Mapping
Am 05.10.2013 um 17:01 schrieb Wolfgang Schuch wolfgang.sch...@adfc.de: OK. Z.B. wüsste ich gerne - mit welchem Werkzeug ich am besten (ja ich weiß, das ist meist Ansichtssache) *cn taggen kann. ich empfehle Dir Josm. Die *cn tags am besten als Route-Relationen mappen und nicht als Attribute am way. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inseln und Inselgruppen
Am 17.09.2013 um 13:27 schrieb Markus liste12a4...@gmx.de: Ist das ein Tagging- oder Rendering-Problem? Beides, für Inseln ist es ein reines Renderingproblem, für Inselgruppen kommt ein tagging-Problem dazu. Wie könnte man das lösen? Vor allem im Renderer, bei Inselgruppen wäre ein spezieller Tag ggf. Hilfreich (z.B. Natural=archipelago ?) bisher 10x in Verwendung http://taginfo.openstreetmap.org/tags/natural=archipelago Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bundestagswahl 2013, Wahlkreise in OSM
Am 08.09.2013 um 17:49 schrieb Tirkon tirko...@yahoo.de: Bei OSM ist die Situatuion anders. Mit zunehmenden Inhalten wird das Editieren für weniger erfahrene Mapper immer schwieriger. Wenn eine zunehmende Komplexität verhindert, dass die Maintainer vor Ort zunehmend im Tag- und Relationsdickicht nicht mehr durchblicken und sich damit an einfache Korrekturen nicht mehr herantrauen, wird es schwierig. Jein, es ist ja nicht so, dass einfache Korrekturen Grenzrelationen einschließen ;-) Wer einen Fehler in Namen ändern will wird durch Relationen oder zusätzliche tags m.E. nicht gestört, genauso wer POIs aller Art eintragen will. Selbst bei Änderungen an Straßen, die Teil von Grenzrelationen sind, kann man z.B. Die Geometrie neuzeichnen für den Teil, den man ändern will, und die Highway Tags transferieren (sowie die Grenze lassen, wenn man es nicht besser weiß), wobei das schon eher in die Richtung geht, dass man die Komplexität ansatzweise durchdringen muss. Ich versuche daher, möglichst nur die Straßen selbst mit den Highway ways zu beschreiben, eine weit verbreitete Unsitte und im Detail m.E. auch weniger genau ist es z.B., die Straßen beim landuse miteinzubeziehen. Einfache Korrekturen sind in osm auch mit viel mehr Relationen der Art Wahlkreis oder Bistumsgrenze noch gut möglich, weil man die ja unangetastet lassen kann (oder wie oben beschrieben belassen), problematischer für Änderungen an Straßenverläufen sind Routen, weil man da im Prinzip wissen muss, wo die lang laufen, weil sie ja nur Sinn machen indem sie die Straßen benutzen. Für alles andere (Features und Flächen sowie Änderungen an Straßen ohne geänderten Verlauf) ändert sich nicht viel, das bleibt einfach. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bundestagswahl 2013, Wahlkreise in OSM
Am 08.09.2013 um 19:23 schrieb Henning Scholland o...@aighes.de: Das liegt aber nur an den Editoren. Wenn du bspw. josm auf einfache Art sagen könntest: Ich möchte jetzt nur Supermärkte und Hotels bearbeiten und josm blendet den ganzen Rest aus (außer Gebäude, Supermärkte und Hotels) und führt im Hintergrund eine Überprüfung aus, die warnt bzw. verhindert, dass man mit einer Aktion andere Objekte verändert, dann wäre es völlig egal, welcher Mist da sonst noch in der DB ist. ;) ich hoffe, das kommt nicht, weil das ist so ähnlich wie in Josm im schraffierten (also nicht vollständig geladenen) Bereich zu editieren: alles hängt irgendwie zusammen und wer nur einen Teil betrachtet macht fast zwangsläufig was kaputt. Was ist das auch für ein Mappen, nur Supermärkte und Hotels, normalerweise geht man irgendwo hin und was einem auffällt trägt man ein, verfeinert und ändert entsprechend. Diese andere Art von Edits (heute mache ich mal Hotels in Bayern) geht doch sehr in die Richtung mechanische Edits, die sowieso nicht so gefragt sind. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bundestagswahl 2013, Wahlkreise in OSM
Am 08.09.2013 um 20:34 schrieb Kolossos tim.al...@s2002.tu-chemnitz.de: P.S: Ich habe gelernt, dass es mit den WAHL.DATEN.HELFER auch noch mehr Interessenten an den Infos gibt, um damit schöne Visualisierungen zu machen: http://wahldatenhelfer.de/ Schade, dass die Open Knowledge Foundation da eine Google Karte auf der Startseite hat Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutschland API
Am 13.08.2013 um 00:43 schrieb Walter Nordmann pil...@hotmail.com: Ich halte absolut nichts davon, bis auf wenige Ausnahmen solche Daten aus OSM rauszunehmen und in eine neue DB zu verlagern. - Autokennzeichen oder Einwohnerzahlen sind mMn wirklich nicht bei OSM gut aufgehoben, da erstere immer mehr ihren geographischen Bezug verlieren und Einwohnerzahlen reine Statistikwerte sind, für die es verläßlichere Quellen gibt. Stimmt zwar, dass man aus OSM in vielen Fällen vermutlich nicht die aktuellsten Einwohnerzahlen bekommt, aber für meine bisherigen (render)Zwecke waren sie bisher immer gut genug, versuche mal, auf globaler Basis für jedes Dorf die Daten zusammenzusuchen und reinzumischen. Was Kfz.kennzeichen angeht habe ich die bisher auch noch nicht vermisst, aber für die Verbesserung der Suche sind sie ggf. nützlich - dabei spielt es ja gar keine Rolle, ob die tatsächlichen Kennzeichen noch in allen Fällen nach diesem Muster funktionieren, es geht eher darum, noch einen weiteren Kurznamen an die Landkreise zu hängen Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 24.07.2013 um 00:39 schrieb Michael Kugelmann michaelk_...@gmx.de: -1, absolut dagegen. Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die Topologie! Da was schon immer so und sollte auch so bleiben. Wenn, dann gebt z.B. für einen Weg eine Breite mittels width == xxx Wir erfassen ja nicht nur einen Graphen, auch wenn der ziemlich nützlich ist. M.E. Ist der Wunsch legitim, auch unterirdische Plätze und Verkehrsräume von öffentlichen Gebäuden mit ihren Grenzen aufzunehmen und nicht nur als linearen Graph, mit einem Malprogramm sollte man das nicht verwechseln, allerdings ist mit derzeitiger Editor-Technik mehr als ein Stockwerk übereinander eigentlich nicht effizient bearbeitbar oder verständlich, von daher ist der Einwand auch nicht völlig unberechtigt. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 07.07.2013 um 15:40 schrieb Tobias Knerr o...@tobias-knerr.de: Den Bordstein als nicht als bauliche Trennung zu behandeln hat auch deshalb eine gewisse Logik, weil er insbesondere für diejenigen Verkehrsteilnehmer, deren Bereich damit in erster Linie abgetrennt wird - nämlich Fußgänger - kein nennenswertes Hindernis ist. Insofern ist er durchaus auch explizit überfahrbar (oder vielleicht übergehbar). Bei Bordsteinen kommt es drauf an, wenn er den Fußweg abtrennt mappe ich das auch noch nicht mit eigener Geometrie, aber zwischen zwei Fahrbahnen ist mir das Grund genug, den Highway zu splitten. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] CMYK und RGB Farben - Standardisierung in OSM
Am 05.06.2013 um 15:46 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wenn dir eine Wiki-Seite reicht, kann ich dir gerne blödsinnige Wikiseiten suchen, die einfach niemanden im Detail interessieren, was der einzige Grund ist, warum sie nicht längst geändert oder gelöscht oder als abgestimmt und als abgelehnt dokumentiert markiert sind (siehe http://wiki.openstreetmap.org/wiki/Category:Proposed_features_%22Rejected%22 ). Wobei selbst ein Eintrag auf dieser Liste nicht immer eindeutig ist, z.B. hier: http://wiki.openstreetmap.org/wiki/Proposed_features/Incline Nur weil es damals 2007 noch nicht möglich war, 15 Leute zur Abstimmung zu bewegen, heißt das ja noch nicht, dass dieser Vorschlag auch in der Zwischenzeit von den Mappern abgelehnt wird: http://taginfo.openstreetmap.org/keys/incline Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 30.05.2013 um 15:05 schrieb Tobias Conradi mail.2...@tobiasconradi.com: Das ist das was bei der Konversion via ECI nocht fehlt. Wenn man aber nur RAL vorgibt, dann erhält man Werte wie hier zu sehen: http://anna.info/wiki/RAL_5017 irgendwelche Blautöne. RAL ist durchaus eindeutig definiert, es gibt da Farbfächer, Farbbibliotheken, Lacke, etc, m.E. sollte der Tag in osm in diesem Fall de:verkehrsblau oder traffic_blue oder RAL_5017 od. ähnlich sein (da das die festgelegte Farbe ist), dann kann sich der Auswerter selbst entscheiden, ob er das in irgendeinem Blau oder sonstwie darstellt, oder das richtige nimmt, vor allem wenn er vorhat, das zu drucken, weil auf Bildschirmen ist korrekte Farbwiedergabe sowieso nicht üblich bzw. möglich. RGB kommt mir nach wie vor aufgrund der Einschränkungen hinsichtlich der darstellbaren Farben nicht als glückliche Wahl vor, welches RGB ist dabei auch bisher noch gar nicht definiert... Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie tag ich eine Parfümerie?
Am 29.05.2013 um 12:46 schrieb gmbo g...@kilometerfresser.eu: Danke für die Info Dann ginge für den Parfümladen ja auch ein subtag beauty. Der wird dafür zwar noch nicht verwendet aber als subtag gibt es den schon. http://taginfo.openstreetmap.org/keys/beauty#map Hauptsächlich in Europa verwendet. Davon halte ich nichts, bisher ist lt taginfo noch keinmal dieser subtag für Parfümerien verwendet worden, m.e. Ist Beauty ein Tag für einen Schönheitssalon, das unterstützt auch der beauty-subtag, und da gehört m.E. eine normale Parfümerie nicht dazu. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 um 15:16 schrieb Tobias Conradi mail.2...@tobiasconradi.com: 2013/5/29 Martin Koppenhoefer dieterdre...@gmail.com: Am 29. Mai 2013 10:05 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Ich meine, es ist sinnvoll, festgelegte Farben so einzutragen, wie sie definiert sind, wenn der Mapper die Information hat. Eine Übertragung in andere Systeme bleibt dem Auswerter überlassen. +1 -2 Die Fragen dazu sind nicht beanwortet http://lists.openstreetmap.org/pipermail/talk-de/2013-May/102425.html http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values Entweder man nimmt einen Key und setzt das entspr. Farbsystem in den Wert also so was wie colour=rgb#ff / white / cmyk 0,0,0,0 / RAL 9003 / RAL Signalweiß etc Oder man setzt das Farbsystem in den Key, colour:rgb=* etc Ich wäre für ersteres, weil man mehr als eine Angabe im Prinzip nicht braucht. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 um 12:52 schrieb Peter Wendorff wendo...@uni-paderborn.de: Für andere dagegen ein echter Wenigerwert: Ich kann aus dem Kopf RGB-Werte ungefähr überprüfen, aber CYK aus dem Stehgreif nicht, Wieso nicht? Additive vs subtraktive Farbmischung, m.E. kann man sich CMYK einfacher vorstellen, weil es der Erfahrung des Mischens von Farben im Farbkasten entspricht, während es nicht so einfach ist, sich das Ergebnis aus der Mischung von verschiedenfarbigen Lichtern vorzustellen. und ehrlich gesagt: besser, da steht light red, oder yellow green und ich kann ungefähr sagen, dass das passt (und es sonst als Fehler markieren), als dass irgendein Mapper X eine Farbtabelle kennt, die er abtippen kann. Die stehen dann drin und wenn er sich vertippt hat, merkt das niemand - für die nächsten Jahre. Entweder es fällt auf, oder es macht auch nichts. Wenn da wirklich jahrelang Quatsch steht und es niemand merkt, dann ist es auch egal ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie tag ich eine Parfümerie?
Am 29.05.2013 um 15:55 schrieb René Kirchhoff rene-kirchh...@arcor.de: Nachtrag: ebenfalls 8x auch mit ie am Ende: http://taginfo.openstreetmap.org/tags/shop=parfumerie 2013/5/29 René Kirchhoff rene-kirchh...@arcor.de 8x gibt es auch shop=parfumery http://taginfo.openstreetmap.org/tags/shop=parfumery Wobei die Regel ist, tags in Englisch zu definieren, von daher scheiden frz. Varianten m.E. aus... Üblich ist die Schreibung mit e und y Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Am 29.05.2013 um 16:17 schrieb Tobias Conradi mail.2...@tobiasconradi.com: 2013/5/29 Martin Koppenhöfer dieterdre...@gmail.com: Am 29.05.2013 um 15:16 schrieb Tobias Conradi mail.2...@tobiasconradi.com: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Den Teil über RGB kann man ruhigen Gewissens aus dem Wiki streichen, hat mit der Realität nichts zu tun, siehe http://taginfo.openstreetmap.org/keys/colour#values Den Teil über RGB (hex triplet) kann man ruhigen Gewissens nicht aus dem Wiki streichen, denn in der Realität werden RGB-Werte genutzt, siehe http://taginfo.openstreetmap.org/keys/colour#values z.B.: #79b51d count: 450 Ja, vor allem da das Wiki ja auch noch Alternativen zu RGB zulässt. Müsste dann nur noch jemand aufschreiben was man in den Fällen macht, wo sich eine Farbe nicht darstellen lässt mit den im Wiki beschriebenen Varianten ;-). M.E. ist das was hierzu bisher entstanden ist, die Sicht von Programmierern, um möglichst einfach die Dinge auszuwerten, sozusagen ein Teil der Renderregeln in tags. Wenn wir eine db sind, die die Welt beschreiben will, dann sollten wir hier flexibler sein und es so gestalten, dass es für den Mapper am einfachsten ist und die Abbildung der Realität entspricht. Ähnlich verhält es sich z.B. mit Geschwindigkeitslimits in mph, die sollte man auch nicht in km/h umrechnen, weil sie eben in mph sind, und man immer was verliert beim Umrechnen (wobei der Verlust im Falle der Farben ggf. größer ausfallen kann). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie tag ich eine Parfümerie?
Am 29.05.2013 um 01:51 schrieb Ruben Kelevra cyr...@gmail.com: wie tagge ich eine Parfümerie? shop=beauty wie im Wiki generisch steht ist doch Blödsinn. Schönheitssalon, Kosmetiksalon, Damensalon, Nagelstudio, Parfümerie, Wellness-Center, aber nicht gleichzeitig Friseursalon. Das ist so als würde man den Supermarkt mit der Wursttheke, den Metzger und den Schlachthof unter einen Tag packen. +1, das scheint neben der Kinderbetreuung ein zweites schwarzes Loch zu sein ;-) Taginfo kennt z.B. shop=cosmetics Vielleicht kommt das ja in Frage, Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Alleen und Baumreihen
Am 25/mag/2013 um 13:05 schrieb Robert rsn@email.de: Aus den Waldgrenzen lässt sich die räumliche Anordnung der Bäume NICHT schätzen. Laut Theorie aber aus der Geschichte und Behandlung des Waldes. Interessanter Exkurs, allerdings ging es nicht um echten Wald sondern um Baumreihen, z.B. von Alleen, die als Flächen gemappt sind. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenCyclaMap als Vektordaten
Am 04.02.2013 um 14:30 schrieb ef...@gmx.de: Hallo zusammen, ich möchte gerne Die OpenCycleMap als Vektordatensatz haben (für das Münsterland). Es wird überall beschrieben, das die Karte auf Basis von OSM Daten gerendert wird. Also muss, nach meinem Verständnis, auch jedem Weg ein Attribut mitgegeben werden, um welchen Fahrradweg (National, bzw. Wabe) es sich handelt, so das ich die OSM Daten danach filtern kann. In OCM wird dies ja auch sauber gerendert und in der Hilfe steht auch das für eine Route die Tags * cn_ref =“Nr“ zu vergeben sind. Wenn ich mir aber nun die OSM Daten z.B. von der Geofabrik lade, finde ich diese Tags nirgendwo. Kann mir da jemand weiterhelfen, bzw. einen Hinweis geben, wo ich die vollständigen Daten herkriege. es gibt 2 alternative Methoden um eine Fahrradroute zu beschreiben, die ältere (und begrenzt mächtige) ist die über tags, z.B. lcn, ncn etc. (local cycling network, national cycling network), die neuere funktioniert über Routen (relations). Infos gibt's reichlich dazu im Wiki, z.B. hier: http://wiki.openstreetmap.org/wiki/DE:Bicycle (auch mit links zu fertigen Garminkarten) http://wiki.openstreetmap.org/wiki/Cycle_routes http://wiki.openstreetmap.org/wiki/DE:Bicycle/Fahrradroutensammlungen … Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tag für Försterei
Am 24.01.2013 um 16:20 schrieb Falk Zscheile falk.zsche...@gmail.com: Ich würde jetzt erst einmal ein landuse=forestry setzen. Da sollte jeder wissen, was gemeint ist und kann es ggf. verbessern. Ich hoffe mal nicht, das es jemand mit landuse=forest verwechselt -- aber das weiß man nie. genau aus dem Grund finde ich landuse=forestry einen schlechten Wert (Forstwirtschaft), weil das genauso auch auf bewirtschaftete Wälder passt. Eher so was wie landuse=forestry_yard oder so (keine Ahnung ob's das Wort gibt, aber selbst wenn nicht könnte so ein Kunstwort gut helfen, Verwechslungen zu vermeiden). Oder landuse=work_yard für einen Betriebshof mit Zusatztag work_yard=forestry (oder yard-type=forestry) oder ähnlich. Oder evtl. landuse=industrial und einen entsprechenden subtag? Industrial passt m.E. nicht so supertoll, aber wo das auch Gewerbe und nicht nur das deutsche Industrie zu umfassen scheint, wäre es vielleicht eine Möglichkeit? Oder evtl. landuse=services? Letzteres ist halt wieder ziemlich generisch und kann alles und nichts bedeuten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tag für Försterei
Am 24.01.2013 um 18:04 schrieb Christoph Hormann chris_horm...@gmx.de: vielleicht als Hinweis, weil es noch nicht erwähnt wurde: für viele andere landuse-Arten gibt es gebräuchliche Zusatztags zur Präzisierung, z.B.: http://wiki.openstreetmap.org/wiki/Key:produce http://wiki.openstreetmap.org/wiki/Proposed_features/Key:product Das ließe sich hier mit einem 'landuse=farmyard' kombinieren, ohne dass das irreführend wäre - man sollte das 'farm' in 'farmyard' vielleicht nicht zu eng auslegen, genau wie eine Fläche mit 'landuse=industrial' ja auch nicht nur für zur industriellen Produktion genutzte Flächen verwendet wird. m.E. sollte man da eher bei industrial nachsteuern, wobei der entscheidende Unterschied ist, dass industrial schon immer auch für Lagerflächen definiert war, und nie nur für Produktion, während farmyard schon immer ein Bauernhof war, und eine Försterei ist m.E. kein Bauernhof. Mit subtags verfeinert man eine gröbere Klassifizierung, aber die subtags sollten im Haupttag schon enthalten sein und nicht erst durch den weiteren tag eingeschlossen werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellung auf lanes AA Wittlich-West
Am 14.01.2013 um 11:10 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de: Ich habe den Mapper schon angeschrieben, da er fast immer Wege als Grenzen zu Flächen nimmt. das ist IMO nicht falsch. Solange die Linie in der Mitte des Weges den ganzen Weg symbolisiert, kann auch die Fläche von der Linie begrenzt werden. m.E. sind das 2 verschiedene Arten von Datenmodell, die man nicht typologisch kombinieren kann. Bei Flächen kommt es z.B. auf die Größe an und darauf, dass die Grenze an der richtigen Stelle liegt (d.h. dass alles, was sich innerhalb der Fläche im Modell befindet, auch innerhalb dieser Fläche liegt, das ist nicht gegeben, wenn man die Flächen bis zur Straßenmitte erweitert). Daneben schafft man sich auch praktische Probleme, wenn man die highway-Wege mit Flächen mischt, erfahrungsgemäß kommt es hierbei öfters mal zu falsch verbundenen Objekten, und ist das beim weiteren Verfeinern mehr Arbeit (weil man diese ganzen Verbindungen wieder auftrennen muss). Abhilfe wäre hier nur ein landuse=highway o.ä. Um den Weg herum einen mehr oder weniger breiten Graben des Nichts zu lassen, halte ich für ... unschön. es ist ja kein Graben des Nichts sondern noch nicht getaggtes Gebiet. Falsch taggen damit nichts weiss bleibt halte ich für die schlechtere Alternative. Die Straßenflächen (und ggf. Straßenabstands/ -nebenflächen) dem angrenzenden Landes zuzuschlagen halte ich für falsch. Insbesondere dann, wenn jemand den Weg verschiebt und der Graben des Nichts dann irgendwo in der Landschaft liegt. die Karte nur halb anzupassen ist immer unschön und führt zu temporären Fehlern, aber m.E. ist das kein Argument für die eine oder andere Art zu mappen. Dann lieber der Weg genau auf der Grenze, und beim Verschieben stimmt zumindest der Zusammenhang wieder. tut er ja nicht ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellung auf lanes AA Wittlich-West
Am 14.01.2013 um 11:30 schrieb Martin Koppenhöfer dieterdre...@gmail.com: typologisch sorry, gemeint war: topologisch (Diese Autocorrection zerschießt einem mehr als dass sie gutes tut). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rechtschreibung Deutsch Englisch Übersetzung
Am 14.01.2013 um 11:43 schrieb Ronnie Soak chaoschaos0...@googlemail.com: 'spatial' hat keine gute deutsche Übersetzung, bedeutet aber in etwa '(meist zweidimensional) räumlich angeordnet'. im Prinzip +1 zu den Erklärungen von Ronnie, bis auf spatial, das entspricht doch ziemlich genau dem deutschen räumlich, (ist ein Adjektiv entsprechend den Substantiven space und Raum (Raum wie Weltraum, Zahlenraum, aber nicht wie Zimmer)). Zweidimensional ist das vielleicht in der Praxis, wenn man sich auf die Erdoberfläche bezieht (so wie z.B. auch in der deutschen Raumplanung der Luftraum eher weniger beplant wird), aber grundsätzlich ist das eher dreidimensional zu sehen, so wie räumlich auch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Fahrzeuge mit Sondergenehmigung auf 2x2 autobahnähnlicher Straße
Am 13.01.2013 um 15:17 schrieb Tirkon tirko...@yahoo.de: auf der Bundesstraße 210 wurde im Landkreis Friesland beim Wilhelmshavener Kreuz ein autobahnähnlicher Lückenschluss vor wenigen Wochen vollzogen und freigegeben. Trotz 2x2 Fahrstreifen mit baulicher Richtungsfahrbahntrennung sind hier landwirtschaftliche Fahrzeuge zugelassen, wenn sie mindestens 40 km/h schnell sind - allerdings nur mit Sondergenehmigung. Es handelt sich offensichtlich um einen Modellversuch. Demzufolge gibt es die Regelung sonst nirgendwo (im Landkreis? / in Deutschland?). Ich habe daher * agriculture=yes m.E. müsste das private sein und nicht yes, da es nur mit Sondergenehmigung möglich ist und * minspeed:agriculture=40 getaggt minspeed, also eine Mindestgeschwindigkeit auf einem Straßenabschnitt ist nicht ganz dasselbe wie eine bauartbedingte Mindestgeschwindigkeit eines Fahrzeugs. Ich würde das weglassen, da die Voraussetzungen erfüllt sind, wenn man mit private Zugang hat. Damit sollte dem nicht-landwirtschaftlichem Benutzer der Straße diese Eigenschaft deutlich werden. wobei agricultural m.W. in Deutschland nicht landwirtschaftliche Fahrzeuge bezeichnet sondern Fahrzeuge, die sich in landwirtschaftlichem Einsatz befinden (also auf die Nutzung bezogen ist und nicht auf den Fahrzeugtyp). Ist der Fall so einzigartig und zudem theoretisch, dass man ihn im Tagging vernachlässigen kann? Falls nein, wie würde man die notwendige Sondergenehmigung taggen? grob schonmal mit private, m.E. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Edits von Nodekiller
Am 12.01.2013 um 10:16 schrieb Frederik Ramm frede...@remote.org: Hallo, On 01/11/2013 10:33 PM, Manfred A. Reiter wrote: Also bei allem Verständnis für automatische Änderungen, habt ein paar Argumente für mich für Schüler, die sich dort mit der Küstenlinie alle Mühe der Welt gegeben haben, die Wanderweg nach GPS tracks nachgezeichnet haben und heute an ihrer Bearbeitung die Leistung von Nodekiller sehen? Hast Du dir die Edits tatsaechlich angesehen und sprichst von einer konkreten Verschlechterung, oder argumentierst Du hier eher theoretisch, basierend auf der Annahme, dass jede Loeschung von Noes automatisch eine Verschlechterung darstellt? ja, im ersten Moment wenn man den File öffnet sieht man gleich, dass das ein automatischer Edit ist (d.h. man würde erwarten, da nie darüber diskutiert wurde, dass die DWG so was reverted, schon aus Prinzip). Konkret wenn man dann ganz reinzoomt und sich das genauer ansieht sieht man (ich) nirgends eine Stelle, an der ein Schaden entstanden zu sein scheint. Es sind nur wenige Noldes, die entfernt wurden, und die Geometrie scheint davon in der Tat nicht oder nur sehr sehr wenig beeinflusst worden zu sein. Interessant wären ggf. mal Stellen wie Kurven im Gebirge (enge 180 Kehren), wo so eine Aktion am ehesten Schaden anrichten würde auch mit eher geringer Toleranz, aber habe nichts derartiges gefunden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multipolygone im Wiki
Am 10.01.2013 um 16:52 schrieb Peter Wendorff wendo...@uni-paderborn.de: Ich halte hier die Variante für intuitiv, dass das Multipolygon eben eine Geometrie hat, und die Attribute des MPs beschreiben genau das, was unter dieser Geometrie zu finden ist - also im Wald, aber nicht im Loch im Wald wie der Lichtung oder dem See. Dies folgt der Analogie aus dem way, dessen Tags das beschreiben, was im entsprechenden Polygon oder aber Linienzug zu finden ist. +1, ich glaube, dass wir es allen Mappern einfacher machen, auch den computertechnisch weniger studierten, wenn wir eine stringente Logik verfolgen, und möglichst keine Ausnahmen und Sonderregeln einbauen. Wenn die tags für ein Objekt der Welt aus mehreren OSM-Objekten (Relation und way) zusammengewürfelt werden müssen ist das ein bisschen seltsam und auch aufwendiger zu hinterschauen. Deiner Argumentation folgend wäre es praktisch nicht möglich, ein Naturschutzgebiet, das Wald, Lichtungen und See im Wald umfasst - es sei denn, man legte ein zusätzliches Polygon deckungsgleich (oder mies getrickst ganz-leicht-abweichend) auf den outer-way des MP. naja, man könnte ein weiteres Multipolygon mit demselben outer way aber ohne die inner ways machen, sofern es sich nicht um tags für eine Linie handelt, überlappende ways bräuchte man deshalb noch nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien-Generalisierung
Am 09.01.2013 um 16:40 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Ich habe eigentlich die Erfahrung gemacht, dass es relativ unproblematisch funktioniert auch auf kleinen Zoomleveln mit den hochaufgelösten Küstenlinien zu arbeiten, das verbraucht IMO keine relvante Rechenzeit. ja, es geht nicht um die Rechenzeit sondern um die Darstellungsqualität. Wenn Du z.B. hier einen ähnlichen Fall ansiehst: http://www.openstreetmap.org/?lat=40.7508lon=17.7167zoom=12layers=M (ist zwar admin Grenze und nicht coastline, aber das Thema ist dasselbe) wirst Du merken, dass je nach Strichstärke und verwendetem Linienverbindungstyp (ob Ecken eckig oder rund werden sollen und bei welchem Winkel) extrem störende Artefakte entstehen können (spitze Ecken, die rel. groß sind und weit über das eigentliche Gebiet hinausragen bei dicken Strichstärken). Auch wird es einigermaßen zufällig, wie eine sehr detaillierte Linie aussieht, wenn man sie auf wenigen Pixeln rendert (ggf. wird das dann ein dicker Brei, oder Inseln werden zugekleistert von der Coastline). Im Hauptstil von Mapnik wird das geschickt umschifft, indem die Küstenlinie überhaupt nicht gerändert wird, aber für manche Kartenstile will man das halt machen, z.B. bei den üblichen Physischen Karten: http://www.mygeo.info/landkarten/amerika/mittelamerika_cia_2007.jpg (Im vg. Beispiel von der CIA kann man auch gleich ein paar Probleme sehen, wie z.B. Land, das meerseitig unter der vereinfachten Küstenlinie hervorlugt (Norden von Kuba), oder Brei wenn es im Küstenbereich eng wird (Orinoco Mündung in Venezuela)). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Vorlagen
Am 07/dic/2012 um 01:24 schrieb gmbo g...@kilometerfresser.eu: Am 06.12.2012 21:36, schrieb Wolfgang Wienke: Hallo, kann man JOSM einfach so modifizieren, dass ein Klick auf Bussymbol/ Bushaltestelle nicht nur die Eigenschaft highway=bus_stop sondern automatisch zusätzlich auch public_transport=platform erzeugt wird? Sehe ich richtig, dass das nicht über ein *.xml-Datei sondern nur über JAVA funktioniert? :-( Das ganze ist wirklich nicht schwer, als Beispiel ist http://wiki.openstreetmap.org/wiki/Stolpersteine#Preset_-_JOSM-Vorlagen ganz gut. Wobei platform für Bushaltestellen am besten deprecated werden sollte, d.h. es macht eigentlich keinen Sinn, das automatisch hinzuzufügen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse nicht für Detailmapping verwenden (war: Abgerissenes Haus)
Am 06/dic/2012 um 11:40 schrieb Henning Scholland o...@aighes.de: Also das Problem, dass Landuse zu sehr zerstückelt wird, kann man damit auch nicht lösen. Ein Problem ist das m.E. nicht, wenn die Mapper versuchen, die reale Situation detailliert in Osm abzubilden. Zum Problem wird es höchstens für den, der für einen bestimmten Kartenmaßstab einen bestimmten Detaillierungsgrad bzw. ein gewisses Generalisierungslevel in den Rohdaten erwartet, und dann von der Vielfalt, die das echte Leben bietet, erschlagen wird. Das kann man aber relativ einfach lösen, indem man vor dem Rendern die Nutzungen automatisch zusammenfasst und kleine Ausrutscher ggf. unterschlägt. Was dabei klein bedeutet hängt vom Maßstab der Karte ab (kann also nur der Kartenersteller entscheiden), und ob die abweichende Nutzung eines kleinen Teilstücks erwähnenswert ist oder nicht kommt neben der Größe vor allem auf die spezifische Nutzung und die Nutzung drum rum an. Da haben sicher auch verschiedene Nutzer unterschiedliche Ansichten, weshalb man sich nicht schon beim Eintragen auf einen usecase festlegen sollte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 03/dic/2012 um 10:32 schrieb Henning Scholland o...@aighes.de: Um bei obigem Beispiel zu bleiben: Es wird immer die Schlacht um Stalingrad sein, aber dennoch würde ich als deutschen Namen der aktuellen Stadt Wolgograd nutzen, weil die Stadt 1961 unbenannt wurde. Sehe ich auch so, daher nochmal der Hinweis auf old_name:de, bzw. bei komplexeren Fällen auch mit Jahreszahl. Ich fände es durchaus wünschenswert, auch mittlerweile ungebräuchliche Namen als solche gekennzeichnet in der dB zu haben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 03/dic/2012 um 11:13 schrieb Gerrit z0idb...@gmx.de: Es lässt sich doch für jeden node herausfinden, in welchem Land er sich befindet, oder nicht? Die Ländergrenzen sind doch alle eingetragen. Sprachgrenzen und Schriftgrenzen aber nicht, und teilweise sind auch mehrere Schriften im gleichen Gebiet offiziell, es sollte deshalb aus dem tagging direkt hervorgehen, in welcher Sprache und falls erforderlich auch Schrift ein Tag ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 02/dic/2012 um 11:48 schrieb Andreas Labres l...@lab.at: Um es nochmal auf den Punkt zu bringen: man denke an eine _ (en) Karte, die also lokale Namen (z.B. auch ein kyrillischer o.a. fremder Schrift) und die englische Variante anzeigen soll. Dann will man aber nicht, dass alle engl. Namen plötzlich doppelt dastehen. Stellt sich die Frage, ob eine Intelligenz im Renderer, die idF identische Strings unterdrückt, da reichen würde. Also an den erwähnten Beispielen [_ (en) Karte]: München wäre dann als München (Munich) und Aachen nur als Aachen (auch wenn's dort ein name:en=Aachen gibt) beschriftet. Das wäre IMO ein gangbarer Weg. Das könnte man im postgres-teil der Regeln sicherlich einfach so einbauen. Das Grundproblem ist damit aber noch nicht gelöst: wie kann man wissen, in welcher Sprache der Inhalt eines bestimmten name tags ist? Wenn man weder den Tag duplizieren will, noch auf das generische name verzichten, dann wäre ein Zusatztag lang o.Ä. dafür gut geeignet. Beispiel: in welcher Sprache ist dieser Node getaggt? http://www.openstreetmap.org/browse/node/621235472 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank / saisonale flußläufe
Am 21/nov/2012 um 10:16 schrieb Henning Scholland o...@aighes.de: wenn man sich etwas in der Welt umschaut, dann stellt man fest, dass solche Situationen (breites Flussbett, wenig Wasser) nicht unüblich sind. Bisher hab ich den Fluss immer nur als way eingetragen, da es mir primär darum ging zu sagen: Hier ist ein Fluss. Ein riverbank-Polygon wird dem ganzen nicht wirklich gerecht, weil ein großteil der Nutzer davon ausgeht, dass riverbank=Fläche mit Wasser. Es gibt auch Fälle, wo das Flussbett 500m Breit ist und dann ein 5m breiter Fluss durchfließt. Da macht dann ein 500m breiter Wasserstreifen auf der Karte einen falschen Eindruck. Einen falschen Eindruck macht das nur, wenn man falsche Erwartungen hat ;-) Derzeit ist ein Großteil der Nutzer eben Mitteleuropäer und geht ggf. mit Erwartungen, die auf seinen Erfahrungen beruhen, an die Interpretation der Karte. riverbank begrenzt das Flussbett, von daher durchaus sinnvoll, ggf. könnte man das noch weiter verfeinern, wenn man es für notwendig erachtet, z.B. bei stark schwankendem Pegel Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank / saisonale flußläufe
Am 21/nov/2012 um 14:43 schrieb Markus liste12a4...@gmx.de: Kartiert wird das Gewässer bei: - mittlerer Abflussmenge (Normalzustand) - hoher Abflussmenge - niedriger Abflussmenge Für OSM bietet sich der *Wasserstand bei mittlerer Abflussmenge* an. Ich denke hohe Abflussmenge macht mehr Sinn wenn man das Flussbett betrachtet, weil auch wenn wo nur für kurze Zeit im Jahr der Fluss fließt, dann ist das prinzipiell doch Flussgebiet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausbau des Toiletten-Templates
Am 19/nov/2012 um 09:53 schrieb Norbert Kück o...@nk-bre.net: Hallo, am 19.11.2012 09:34 schrieb Jan Tappenbeck: Wie taggt man einen Wickelraum - im Wiki habe ich schon zum Begriff Baby nichts gefunden. Einer Ideen ? Da braucht es Ideen? Nein nur ein Wiki. RDFW, Jan. Im Wiki habe ich diaper=yes gefunden, aber als Attribut. Mit diesem Windel=ja ist ein Wickelraum gemeint? Soll man das benutzen, bzw. Windel=Zimmer (diaper=room) um eine solche Einrichtung zu taggen? M.E. sind die zumindest teilweise besser als Feature getaggt (d.h. eigenständiges Objekt z.B. im amenity-Raum) denn als Attribut. Nur Windel ist auch ein bisschen kurz, wurde dieser Tag denn jemals auf der internat. Liste den Natives vorgestellt? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] fixme sinnvoll?
Am 10/nov/2012 um 10:03 schrieb Falk Zscheile falk.zsche...@gmail.com: wäre es beispielsweise (noch) legitim ein fixme=Postleitzahl zu setzen, wenn ich eine Adresse eingegeben habe, mir aber die Postleitzahl unbekannt ist? M.E. sind fehlende tags selten einen anderen tag (fixme) Wert. Dass ein tag fehlt lässt sich in diesen Fällen praktisch immer automatisch feststellen. Ausnahmen sehe ich da, wo der Mapper einen Verdacht hat, sich aber nicht ganz sicher ist, z.B. ob eine Straße eine Einbahnstraße ist, oder ob es an einer best. Stelle eine Geschwindigkeitsbegrenzung gibt, etc. Grundsätzlich sollten die Werte in Englisch sein, wer deutsche Werte einträgt sollte dafür tags mit :de postfixen, also description:de, fixme:de, note:de, etc. insbesondere, wenn er im Ausland mappt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Plattform für Gastronomie / Lizenzfrage
Am 06/nov/2012 um 10:35 schrieb Felix Ebert f.ebert@gmail.com: gute Idee! Man könnte diese Informationen bereits aktuell über Tags hinterlegen (Profil bearbeiten - Reiter Social / Tags). Bei OSM scheinen diese Informationen im Tag stars hinterlegt zu werden [1], dementsprechend würde ich das auch bei gonam eintragen. Grüße, Felix [1] http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant -1 für stars bei restaurants. Vor kurzem wurde bei Häfen ein System der Art award:michelin vorgeschlagen (dort hieß es Blue flag). Das finde ich deutlich besser, stars kommt aus dem Hotelbereich, ist aber auch da eigentlich zu unspezifisch, weil es verschiedene Systeme gibt. In jedem Fall würde ich das System bzw. Denjenigen, der die Auszeichnung vergibt, in den Key übernehmen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbanken
Am 23/ott/2012 um 23:33 schrieb talk-de-boun...@openstreetmap.org: Hier müsste ich dann die Datenbank um die zusätzlichen Felder erweitern? Du kannst auch schon beim Import über eine osm2pgsql Option die Daten nach 900913 projizieren. Mit --help siehst Du alle Optionen, es gibt aber auch im Wiki eine Beschreibung. Theoretisch kannst Du auch onthefly projizieren, aber das ist natürlich weniger performant. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Features von Gebäuden, weclhes Schema?
Am 07/set/2012 um 10:05 schrieb Tobias Knerr o...@tobias-knerr.de: Am 07.09.2012 09:45, schrieb Lars Schimmer: http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings roof:shape=flat Dieses Schema kann wohl als einigermaßen standardisiert gelten und man kann bei der Verwendung davon ausgehen, dass die eigene Arbeit auch tatsächlich in Anwendungen auftaucht. Was ich an dem Schema seltsam finde, ist die Definition von http://wiki.openstreetmap.org/wiki/Key:building:levels Damit wird laut Schema im Fall von Brückengebäuden und kragenden Bauteilen nicht die Anzahl der Stockwerke die das Gebäude hat beschrieben, sondern die Anzahl, die es bei durchschnittlicher Stockwerks-Höhe hätte. D.h. Ein zweigeschossiges Bauteil wird z.b. Mit 7 getaggt, wenn es sich in entspr. Höhe befindet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Brücke
Il giorno 12/lug/2012, alle ore 15:45, Markus liste12a4...@gmx.de ha scritto: Hallo Martin, Umriss der Brücke mit building=bridge Wäre visuell simpel zu verstehen. Auch Brückenpfeiler könnte so gezeichnet werden. Ja, das wird ja auch schon allgemein gemacht, Z.B. http://www.openstreetmap.org/?lat=49.022548lon=12.09803zoom=18layers=M bei gleichem Layer Schwierig wären mehrere verbundene Rampen mit unterschiedlichem Layer... Entweder haben sie denselben Layer, dann ist es dasselbe, oder unterschiedliche, dann sind es unterschiedliche Objekte. Oder man definiert die Straßen jeweils einen Layer über dem Brückenobjekt und betrachtet das jeweils getrennt (mit eigenem Layer). Was ja durchaus vorkommt sind mehrgeschossige Brücken, da müsste man die Stockwerksanzahl dem Brückenumriss mitgeben. Wie man die Layer definiert müsste man sich am besten vorher überlegen und dokumentieren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt des Monats Oktober - Trinkwasser
-Urspr. Nachricht- Betreff: Re: [Talk-de] Projekt des Monats Oktober - Trinkwasser Von: Peter Wendorff wendo...@uni-paderborn.de Datum: 01.10.2010 10 (außer bei Tag-Änderungen wie curb-kerb, die aber aus technischen Gründen abgelehnt wurden. Ja? Wann war das? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt des Monats Oktober - Trinkwasser
-Urspr. Nachricht- Betreff: Re: [Talk-de] Projekt d Von: Peter Wendorff wendo...@uni-paderborn.de Datum: 01.10.2010 17:57 Sorry, falsche Erinnerung: abgelehnt wurde das nicht (Martin, Du hattest es ja selbst angesprochen), auf die Nachricht kam keine Reaktion. Die Nachricht selbst war am 22.09.2010, und du argumentiertest, BE sei Standard in OSM, deshalb solle man das ändern. Die Nicht-Reaktion habe ich in meiner Erinnerung wohl so interpretiert: - niemand ist gegen die Aussage, British English sei Richtlinie für Tagnamen - Die Änderung des Tags selbst ist für die meisten zumindest nicht so erstrebenswert, dass eine Antwort darauf dem zustimmt Ich denke eher, das nutzt noch keiner groß, kann man also noch problemlos a npassen Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
