Re: [Talk-de] Niedrigwasserlinie
oder einfach mal im Wiki nach Tides suchen ;-) http://wiki.openstreetmap.org/wiki/User:Skippern/INT-1#H:_Tides.2C_Currents Gruß Mario Am 9. Dezember 2010 19:47 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, Am Donnerstag 09 Dezember 2010 18:51:57 schrieb Stephan Wolff: Moin, auf den Luftbilder von Bing sind auch die Niedrigwasserlinien an der Unterelbe und in Teilen des Wattenmeeres abschätzbar. Gibt es schon Vorschläge, wie die trockenfallenden Gebiete in OSM zu erfassen sind? Für die Niedrigwasserlinie könnte man natural=low_tide_line nehmen. Um einem Renderer eine einfache Möglichkeit zur Darstellung zu geben, wäre eine Erfassung als Fläche allerdings besser als eine einfache Linie. Da würde ich die Leute von openseamap kontaktieren. Wenn die eine Seekarte machen wollen, gehören Höhen- und Tiefenangaben da irgendwann auch rein. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Panzersperren des Westwall
http://www.openstreetmap.org/?lat=50.81016lon=6.02959zoom=15layers=M Am 21. November 2010 19:14 schrieb Steffen Heinz eifelhu...@gmx.de: Auch wenns ein unrühmliches Bauwerk ist Wie sollten die Panzersperren des Westwalls eingetragen werden? (teilweise läuft ein Weg dort, der eingetragen ist). Ist das ein Bodendenkmal? Das Teil ist ja endlos lang... In großen Teilen ist diese Bauwerk geschützt, auffällig usw. Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Hi MArtin, also aus Sicht des Flugzeugs finde ich diese 3teilige Angabe eigenltich sehr eindeutig. height ist in diesem Zusammenhang die Distanz zwischen der Position in der Luft bis zu einer Materie ungleich Luft (der Grund/boden/Oberfläche)... und elevation ist die lotrechte Distanz vom Meeresspiegel zu diesem natürlichen Grund/Boden-Level (bei Seen z.B. ein Füllstand-Mittelwert?) Haben wir hier keine Segelflieger, die das verifi- oder falsifizieren können? Die sollten doch die Definition bestimmt kennen ;) Auf der Suche nach der Wahrheit grüßt Mario Am 24. August 2010 10:14 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com : Am 23. August 2010 23:24 schrieb Mario Salvini salv...@t-online.de: - *height* (HGT) ist die Höhe über GND (ground)... - *altitude* (ALT) ist die Höhe über... - *elevation* (ELEV) bezeichnet die Entfernung von MSL (mean sea level)... das macht uns hoffentlich alle etwas schlauer :-) wieso sollte das hilfreich sein? Zur Frage, ob elevation bei Seen die Oberfläche oder den Grund angibt hilft das kein Stück weiter. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Hi Rolf, da sind wir uns alle einig. Die Frage ist halt, was für eine elevation bzw. was für eine height hast du, wenn du, sagen wir mal, über dem tiefsten Punkt eines Sees mit deinem Flieger 20m über der Wasseroberfläche fliegst? Aus dem laienhaften Bauch raus beurteilt würde ich sagen - height=20, ele=vertikaler Abstand zum Meeresspiegel depth=Tiefe des Sees, egal wie tief der See ist... Gruß Mario Am 24. August 2010 18:25 schrieb Rolf Meyerhof r...@meyerhof-net.de: Hi Mario Als langjähriger Motorflieger kann ich die Angaben von Martin bestätigen. Der wichtigste Wert für uns Flieger ist die Elevation. Mit dem Wert wird vor den Start die Höhe des Platzes über NN (oder wie das Heute heisst?) eingestellt damit man bei der Landung auch weiß wie hoch man noch ist. Gruß Rolf -Original Message- From: talk-de-boun...@openstreetmap.org [mailto:talk-de- boun...@openstreetmap.org] On Behalf Of Mario Salvini Sent: Tuesday, August 24, 2010 6:15 PM To: Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] Tiefenangabe als Name Hi MArtin, also aus Sicht des Flugzeugs finde ich diese 3teilige Angabe eigenltich sehr eindeutig. height ist in diesem Zusammenhang die Distanz zwischen der Position in der Luft bis zu einer Materie ungleich Luft (der Grund/boden/Oberfläche)... und elevation ist die lotrechte Distanz vom Meeresspiegel zu diesem natürlichen Grund/Boden-Level (bei Seen z.B. ein Füllstand-Mittelwert?) Haben wir hier keine Segelflieger, die das verifi- oder falsifizieren können? Die sollten doch die Definition bestimmt kennen ;) Auf der Suche nach der Wahrheit grüßt Mario Am 24. August 2010 10:14 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com : Am 23. August 2010 23:24 schrieb Mario Salvini salv...@t-online.de: - *height* (HGT) ist die Höhe über GND (ground)... - *altitude* (ALT) ist die Höhe über... - *elevation* (ELEV) bezeichnet die Entfernung von MSL (mean sea level)... das macht uns hoffentlich alle etwas schlauer :-) wieso sollte das hilfreich sein? Zur Frage, ob elevation bei Seen die Oberfläche oder den Grund angibt hilft das kein Stück weiter. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Hab gerade nochmal etwas die INT-1 durchstöbert... bei Lichtern (egal ob als Bojen im Wasser oder Leuchttürme an Land) wird die Position des Feuers im Verhältnis zum Höhen-Datum mit dem Begriff elevation beschrieben (P16: Elevation of focal plane above height datum); meist irgendein Standardwasserpegel (in der Nordsee z.B. Amsterdamer Pegel (NAP)). Die Sektion H in der INT-1 is vielleicht hilfreich zu diesem Thema... Ein See mit der ele=160 und am tiefsten Punkt eine ele=120 ist halt 40m tief. Bei Meeren fehlt uns aber leider dieser Bezugspunkt, da das Polygon Meer schwierig zu erfassen ist. Vielelicht können wir das mit ele=* (für den Grund) und mean_sea_level:ele=* (für die vertikale Position der Wasseröberfläche) differenzieren? Gruß Mario Am 24. August 2010 21:13 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com : ich habe die Frage auch mal an Tagging gestellt, und da sagte man, ele für den Wasserspiegel an das See-polygon taggen (sinnvoll, da der Umriss ja wirklich die Höhe hat). Für einzelne Messpunkte im See hingegen den Boden (Grund des Sees), und über depth könnte man dann zusätzlich die Tiefe taggen (das ist allerdings eigentlich überflüssig, da sie sich ja über die Differenz Umriss zu ele am Punkt ergibt). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Hi Martin, is halt die Frage, was bei einer Wasseroberfläche der Boden ist bei Flughäfen wird die Höhe ja auch in ele=* erfasst. Für mein Verständnis ist bei einem See oder einem Meer der Boden die Wasseroberfläche, der feste Boden aber das Fluß- See, Meeresbett. Somit könnte man mit natural=water ele=20 (also 20m über N.N.?) + depth=40 (also 40m Tiefe ab Oberfläche) seabed=* einen 40m tiefen See dere 20m über N.N. (oder einem anderen genannten Datum) beschreiben. Gruß Mario Am 23. August 2010 11:27 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com : Am 22. August 2010 16:19 schrieb Mario Salvini salv...@t-online.de: wäre das was du meinst nicht eher die elevation? also sowas wie: natural=water (Anm.: korrigiert) ele=-10 (z.B. bei Seen hinter Deichen die eigentlich unter Normalnull liegen) ? M.E. ist elevation die Angabe der Höhe des Grunds (Boden) in WGS84. Daher bezeichnet es nicht die Höhe des Wasserspiegels. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Hi Fabian, wikipedia schreib aucht: - *height* (HGT) ist die Höhe über GND (ground) (AGLhttp://de.wikipedia.org/wiki/Above_ground_level), also über dem Boden. Mit *height* wird auch z.B. die Höhe eines Turmes angegeben. - *altitude* (ALT) ist die Höhe über MSLhttp://de.wikipedia.org/wiki/H%C3%B6he_%C3%BCber_dem_Meeresspiegel, bzw. NN (ELEV + HGT = ALT). - *elevation* (ELEV) bezeichnet die Entfernung von MSL (mean sea level) bis zum Boden (GND). das macht uns hoffentlich alle etwas schlauer :-) http://wiki.openstreetmap.org/wiki/Key:ele sagt übrigens das Gleiche :) Vielleicht gilt das aber auch nur für die Fliegerei und es gibt unterschiedliche Ansätze... Gruß Mario Am 23. August 2010 23:16 schrieb Fabian Schmidt fschm...@informatik.uni-leipzig.de: Am 23.08.10 schrieb M∡rtin Koppenhoefer: M.E. ist Grund bzw. Boden in jedem Fall nicht aus (flüssigem) Wasser. Ich gehe davon aus, wo ich mich als Mensch befinde, wenn ich mich dorthin bewege, also typischerweise an der Oberfläche des Sees. Leider lese ich aus http://en.wikipedia.org/wiki/Elevation eher Deinen Standpunkt heraus. Lesen hier Geographen mit? Gruß, Fabian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Hi Falk, wäre das was du meinst nicht eher die elevation? also sowas wie: nature=water ele=-10 (z.B. bei Seen hinter Deichen die eigentlich unter Normalnull liegen) ? Hab gerade mal ein bischen in der Wiki gestöbert: die OseaM Leute hatten dazu folgene Tagging Schema: seamark:depth=''##.#'' (korrigierte Tiefe in Meter) + seamark:depth:rough=''###.#''(rough data) + seamark:depth:time= (Mess-Datum und -Zeit: JJMMDDHHMM) + seamark:depth:mesurement=(unter: Wasserspiegel | Kiel | Sensor ) + seamark:depth:sensordepth=''##.#'' (Einbautiefe des Sensors unter Wasserspiegel) + seamark:ship:draft=''##.#'' (Tiefgang des Schiffes) + seamark:depth:tide=yes/no (Wert mit Tidenunterschied korrigiert?) + seamark:depth:sensor=yes/no(Wert mit Sensorposition korrigiert?) Find ich einen guten Ansatz. Vereinfacht könnte man daraus machen: depth= depth:rough= depth:time= depth:datum= depth:sensor_depth= depth:ship_draft= depth:tide_correction= depth::sensor_correction= wobei depth= und depth:datum= sollte genügen. Alle anderen Daten dienen ja eher zum genauen bestimmen der korrigierten Tiefe Im Proposal hat man bzgl Tiefe wohl jetzt auch etwas mehr in der INT-1 gestöbert. --- depth:source_quality= possible values corresponding to the INT-1 existence_doubtfull sounding_doubtfull reported reported_not_confirmed depth:source_quality:reportyear= the year where the depth was reported -- kombiniert könnte Tiefe also beschrieben werden mit: depth=* depth:datum=* depth:source_quality=* depth:source_quality:reportyear=* Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Am 21. August 2010 03:47 schrieb Olaf Hannemann ohannem...@gmx.de: Hallo Christian, [...] Wenn alles super funktionieren würde, könnte ich die Seezeichen die nach dem proposal getaggt sind rendern und bräuchte kein eigenes Schema. ;-) Leider habe ich mit dem proposal 2 bis 3 Probleme und da diese nicht verhandelbar sind, muss ich etwas eigenes benutzen. Ich bin auch gerne bereit auf einer größeren Ebene über diese Probleme zu diskutieren. Da ich zur Zeit leider nur sehr wenig Zeit habe, werde ich anfang der Woche zu diesem Thema einen extra Thread auf machen. Bitte habt bis dahin Geduld. Ich finde es wirklich blöd eine Diskussion anzufangen und dann nicht mehr zu antworten. ... Wenn ich mir so die History des Proposals anschaue sehe ich da kein Problem/keinen Sachverhalt, der nicht zur Diskussion stände. Vielleicht einfach mal versuchen? Die Chance, dass sich was Gutes für alle draus entwickelt ist groß :) Da gebe ich dir recht. Das Beste M.e. ist wir setzen uns zu einem kleinen Rundentisch zusammen und versuchen dafür eine Lösung zu finden und geben dann die Ergebnisse bekannt. Bis dahin... Wie die Vorredner schon gesagt haben- der runde Tisch ist hier... Der runde Tisch muss ersteinmal klären wer was wie und warum schreibt. Erst wenn wir uns sicher sind, dass wir uns nicht mehr gegenseitig die Arbeit kaputt machen, können wir das eigentliche Problem angehen. das klingt bei dir so, als würdest du auf eine Delegation von (gewählten/ernannten?) Entscheidungsträgern warten? Auch fänds ichs schon deine Perspektive des gegenseitig Kaputtmachens erzählt zu bekommen. Klar gabs da am Anfang einige Missverständnisse, aber das letzte gute Jahr dümpeln doch quasi beide Ideen kontaktfrei nebeneinander durch die Karte. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Am 21. August 2010 16:42 schrieb Olaf Hannemann ohannem...@gmx.de: Hallo Mario, [...] das klingt bei dir so, als würdest du auf eine Delegation von (gewählten/ernannten?) Entscheidungsträgern warten? Auch fänds ichs schon deine Perspektive des gegenseitig Kaputtmachens erzählt zu bekommen. Klar gabs da am Anfang einige Missverständnisse, aber das letzte gute Jahr dümpeln doch quasi beide Ideen kontaktfrei nebeneinander durch die Karte. Gerade dadurch, dass beide Ideen kontaktfrei durch die Karte dümpeln, geht es ja in 95% aller Fälle gut. Sollten wir aber wieder ein gemeinsames Tagging- Schema benutzen, haben die Änderungen des jeweils Anderen wieder direkten Einfluss auf beide Karten. Hi Olaf, den Gedankengang verstehe ich nicht. Wenn wir doch ein gemeinsames Tagging-Schema benutzten (und dass ist hoffentlich auch das erstrebte Ziel) dann gibts doch kein wir, die, er, sie, es,... sondern nur noch uns. Und wenn dann jemand was ändert ist es doch gerade der Sinn, dass alle Dienste, welche die OSM-Datenbank nutzen, auch Enfluss nehmen..? Gruß Mario PS: wenn ich auf Antwort klicke steht dein Name automatisch mit bei Addressat, dachte das wäre so gewünscht. Werde ihn manuell jetzt immer entfernen. War also keine Absicht :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Tagging Seamarks
2010/8/20 Christian Wagner wagnerschrist...@gmail.com .. Unfortunately I want both- OSeaM cannot show most of my safewater buoys, doesn't render white light beacons etc- for sure nobody is perfect, so no offence. FT has some other drawbacks (e.g. no proper Garmin maps). Recommending to choose the editor of the project which one wants to see their work rendered doesn't cut it. This leads to something like in the baltic sea where FT data is allmost complete, OSeaM shows you nothing: http://www.freietonne.de/seekarte/?zoom=13lat=54.55132lon=13.14014layers=0B0T Hi Christian, the problem for a Garmin-Map at the moment is the limited value of possible Icons in the Garmins (around about 30-60 icons only). But FT, vor example has over 300 different icons, raising tendency ;) Regards Mario ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] S-57 in OSM
Am 17. August 2010 19:36 schrieb Arne Johannessen a...@thaw.de: ... Ob das gelingt oder nich sollte da diskutiert werden. OK, ich besorge mir dann endlich mal einen Wiki-Account und mache da ein paar Anmerkungen auf der Diskussions-Seite. Allerdings hielte ich sehr viel davon, nicht alle nautischen Themen auf einer einzigen Seite zu diskutieren (wird sicher sonst bald sehr unübersichtlich), sondern die Themen aufzusplitten. Anbieten würde sich hier die Einteilung der INT 1. Grüße, Arne Hi Arne, das Proposal bekommt jetzt eh mal ein Clean-up. Welche Einteiung würdest du denn nach INT-1 vorschlagen? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Am 17. August 2010 20:32 schrieb Frederik Ramm frede...@remote.org: Hallo, Arne Johannessen wrote: Dies, also die Nähe des Proposals zu S-57, kann ich überhaupt nicht feststellen. Das ist aber, wie schon angedeutet, auch Sehr Gut So (mit großen Anfangsbuchstaben). Auf [OSM-talk] fiel auch gerade der Begriff S-57 (im Thread Tagging Seamarks). Ich will die Stränge jetzt nicht redundant führen, daher gerade nur so viel: S-57 ist ein eigentlich veraltetes, binäres, äußerst unflexibles Datenformat, dessen Methodik bei der Kategorisierung und Auszeichnung von Geodaten mit der Technik und den Werten von OSM grundsätzlich inkompatibel ist. S-57 zu folgen, ist also *nicht* anzustreben. Vielleicht sollte das jemand auch der internationalen Community mal so sagen. Fuer die stellt es sich im Moment so dar (nach dem, was Malcolm Herring in diesen Thread geschrieben hat): * OpenSeaMap ist der Standard fuer Hochseemapping, * FT wird mehr fuer Binnengewaesser eingesetzt * und sonst gibt es nix. Dass es, wie ich dieser Diskussion hier jetzt entnehme, noch etwas drittes gibt, naemlich ein OpenSeaMap- und FT-unabhaengiges Taggingschema, ist glaub ich keinem so richtig klar. Darauf sollte entsprechend hingewiesen werden. Aber nicht von mir, ich bin eine Landratte. Bye Frederik Hi Frederik, vielleicht nochmal für alle hier beschrieben: FT hat keine eigenes Tagging-Schema. Haben Sie nie gehabt und nie angestrebt. FT hat eine eigene DB die erstmal völlig autark von OSM ist. Für einen Export zu OSM richtet sich FT nach dem offiziellen Proposal auf der OSM-Wiki, wo jeder mitmachen kann. Dann gibts da noch das Projekt OpenSeaMap. Von außen betrachtet ein kleiner Zirkel von Leuten, die (mehr odler weniger für sich) etwas entwickeln haben. Auch nach mehrmaligen Einladungen mit Ihre Ideen mit ins Wiki-Proposal beizusteuern, ist da leider nicht wirklichw as passiert, sondern Sie entwickeln halt ihr Ding weiter. Warum es sich im Laufe der Zeit immer auf FT vs. OseaM hinausläuft, wissen nur die Götter... Ich suche da aber auch mittlerweile nicht mehr nach dem Ursprung und dem Sinn. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Hi Martin, im Grunde hast du schon recht. Als Gegenargument könnte man nennen, dass auf der anderen Seite nicht jeder Funkmast von See oder vom Fluß aus sichtbar ist, bzw. als Orientierungshilfe dienen kann; also keine brauchbare Landmarke ist. ;-) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Am 16. August 2010 23:35 schrieb Arne Johannessen a...@thaw.de: Mario Salvini wrote: seamark=* soll bedeuten, dass da haptisch und tatsächlich ein Gegenstand ist, welcher für einen Schiffs- oder Bootsführer von Bedeutung sein kann. Gerade bei Anfahrten von See spielt dabei auch die Skyline bzw. die Topologie der Küste eine wichtige Rolle. Somit kann es also schon sinnig sein einem Hochhaus oder einem markanten Klippe, einem Funkmast oder eben auch einen (egal aktiv oder nicht) Leuchtturm ein seamark=landmark zu geben. Nochmal frisch in der S-4 nachgeschlagen habend (B-340), wird mir klar, dass Mario Recht hat. Ein derartiges Tag wäre schon mehr als nur ein Renderer-Hint. Der Renderer kann ja nicht wissen, welche Objekte an der Küste tatsächlich prominent zu sehen sind (z. B. abhängig vom Hintergrund, Relief, Farbe etc.). Das ist eigentlich keine kartographische Generalisierung, sondern eine nautische Bewertung als Kartengrundlage. Das Tage würde ich dann aber vielleicht anders nennen, denn die IHO definiert ausdrücklich (eigentlich durchaus logisch): landmark ungleich seamark Wie wäre es mit einfach nur: landmark=* (z. B. landmark=yes oder landmark=prominent) Im Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging#Landmarks ist das Konzept für landmark zwar ein etwas anderes. Für die meisten der dort genannten Arten von Landmarken sollten aber sowieso andere (nicht-nautische) Tags gesetzt werden (z. B. landuse=cemetery), wodurch ein gleichlautendes nautisches Tag (wie landmark=cemetery) dann sowieso redundant wäre. stimmt. im Proposal wird dabei mehr auf die S57 bezug genommen, die mit dem Akronym LNDMRK (Landmark) und dem Attribut CATLMK (Category of Landmerk) die Möglichkeit bietet Landmarken zu beschreiben. Aber vermutlich habt ihr recht und wir können das Dank OSM und der schon vorhandenen TAGgin-Kultur anders die gleichen Sachen erfassen (z.B. für cemetry, winmill, tower, etc..) Mit landmark=yes/promentent/whatever könnt ich mich persönlich auf jeden Fall durchaus anfreunden. :) Das seamark=landmark ist ebenfalls redundant und fiele weg, und das landmark-Tag ist dann schön erweiterbar mit Werten wie landmark=conspicuous für besonders auffällige Objekte usw. (Mögliches Problem: Landmarken für die Luftfahrt?) vielleicht im zweifelsfalle ein landmark:naval=* oder landmark:aerial=* ? Bei den Baken haben wir ja im Grunde ein ähnliches Problem mit Luft unf Wasser ;) Leuchttürme sind allerdings von Natur aus mal mindestens Landmarken, weswegen ich für man_made=lighthouse dann den Default-Wert landmark=yes vorschlagen würde. Meinungen? Grüße, Arne http://www.iho-ohi.net/iho_pubs/IHO_Download.htm#special guter Link. Danke :) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Am 17. August 2010 03:21 schrieb Andreas Labres l...@lab.at: On 11.08.10 21:24, Jan Jesse wrote: water:depth= Mich würde mal interessieren, wieso der key so heißen soll? Welche water:* oder welche *:depth gibt's sonst noch? Servus, Andreas du fragst dich auch, warum nicht einfach depth=* me, too *g* Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Hi zusammen Am 15. August 2010 14:59 schrieb Jan Jesse j...@jesse.de: ... seamark:depth=3.0 water:depth=5.0 ... Beste Grüße von der Dahme JJ seamark:depth macht in soweit ja keinen Sinn, weil da kein SEEZEICHEN ist, welches 3Meter tief ist. In soweit als TAG für die Erfassung von Wassertiefen ungeeignet. water:depth=X oder sogar ganz simple depth=X würden die Sachen doch auch und sogar sinnklarer erfassen (IMO) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Am 15. August 2010 17:34 schrieb Jan Jesse j...@jesse.de: Hallo Mario, seamark:depth macht in soweit ja keinen Sinn, weil da kein SEEZEICHEN ist, welches 3Meter tief ist. In soweit als TAG für die Erfassung von Wassertiefen ungeeignet. Das hatten wir ja schon, ich glaube, das ist inzwischen soweit mehrheitsfähig. water:depth=X oder sogar ganz simple depth=X würden die Sachen doch auch und sogar sinnklarer erfassen (IMO) ganz simpel depth=x halte ich für schwierig, weil wir in der Regel einen Node vor uns haben werden (glaube ich jedenfalls), und der Bezug zum Wasser dargestellt werden muß. Denn unter dem Wasser kann ja ein Erdölvorkommen sein. Das erfassen wir zwar momentan noch nicht, aber wer weiß schon, auf welche Ideen wir noch kommen :-) Lies mal ein paar Tage rückwärts (ich glaube so bis 20.07.10), da sind wir schon einiges durchgegangen ;-) Ach ja, nochmal: Schön, daß Du wieder da bist! JJ hab gerade mal in der S57 geschaut. da gibt es für die Konkretisierung der vertikalen Angaben den Wert: Vertical Datum. (http://www.caris.com/S-57/attribut/verdat.htm). Damit könnte man die Angabe *water:depth=XX* mit z.B. * water:depth:vertical_datum=** spezifizieren. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Am 3. August 2010 07:54 schrieb Martin Simon grenzde...@gmail.com: Am 2. August 2010 18:28 schrieb Rolf Meyerhof r...@meyerhof-net.de: Ich würde alle schifffahrtrelevanten Angaben in OSM mit seamark kennzeichnen, sie sind besser zu unterscheiden. Ich bin zwar Landratte, aber hier möchte ich mir doch einen Kommentar erlauben: wenn ihr wirklich alles schiffahrtsrelevante in OSM(!) in den seamark:-Namensraum schieben wollt, werdet ihr in Konflikte mit etablierten tags kommen. Türme, Schornsteine, Windkraftanlagen und was sonst noch schiffahrtsrelevant sein mag, existieren in OSM unabhängig davon, ob ein Projekt sie zur Erzeugung von Seekarten, für Wanderkarten oder etwas ganz anderes verwenden will: das Objekt wird als das beschrieben, was es ist und gefiltert wird an der Ausgabeseite. Hier sollten wir Neutralität wahren und unter den Sub-Projekten, die ihre Daten in OSM speichern, sollte m.E. keines gleicher als die anderen auftreten. (eventuell habe ich den Satz ja auch falsch interpretiert...) Es m.e. wichtig wie so eine Tiefenangabe entsteht und auch auf was sie bezieht, denn Wasserstände variieren bekanntlich. Wenn du die Karten von OpenSeaMap betrachtest wirst du merken, dass es dort keine Angabe von Wassertiefen gibt. Das sieht so aus als ob wir dass nicht könnten. Wir meinen das Wassertiefen, die eben mal mit einem Echolot oder einen Lot messen zu ungenau und auch gefährlich für die Schifffahrt sind. Wenn wir eine Messmethode gefunden haben oder die Angaben vom BSH bekommen dann werden wir auch die Tiefen in der Karte darstellen. Wäre es ein Problem, Wassertiefen (nur) dann zu rendern, wenn sie zusätlich mit source=BSH oder amtlich=jawoll oder einem anderen tag, das die Vertraulichkeit sicherstellt, gekennzeichnet sind? Dann könnte seamark den vor Ort vorhandenen, designierten Schiffahrtsmarkierungen vorbehalten sein... Gruß, Martin sprichst mir aus der Seele Martin, ein seamark= bezeichnet nunmal ein Seezeichen und nicht irgendeinen Namensraum. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Am 15. August 2010 19:03 schrieb Rolf Meyerhof r...@meyerhof-net.de: Hallo Jan Leider hast Du meine letzten Worte doch nicht verstanden. Ich komme auf Dich zu um einen Termin festzulegen. Hier über die Liste zu posten bringt wirkliche keine Fortschritte. Hab noch etwas Geduld. Dann kriegen wir das schon hin. Mit freundlichen Grüßen Rolf Hi Rolf, wozu immer Termin zum runden Tisch? Wenn OseaM gemeinsamen Konsens anstrebt, müsste man sich einfach den Diskussionen in der OSM-Wiki stellen und nicht einfach imemr im kleinen Kreise irgendwas setzen und da einfach reinhaken. just my 2cents Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Hi Olaf, mal ganz kurz: es gibt keine FT-Tags, sondern nur ein Proposal in der OSM-Wiki, welches sich mit dem Entwickeln eines sowohl detailgenauen als auch menschliche les- und vor allem -schreibbaren Schema beschäftigt. Du wurdest auch schon mehrmals - auch von mir persönlich - dazu eingeladen da mit zu diskutieren, um gemeinsam eine Lösung zu entwickeln. Scheinbar hast du aber da nicht wirklich wenigstens regelmäßig mitgelesen. Weil sonst wüsstest du, dass landmark=lighthouse da z.B: ein Diskusionsthema war. Was die anderen Sachen angeht, wer was wem umgetaggt und/oder Fehler erzeugt hat is schon so lange her, dass ich es 1. nicht mehr weiß es mir 2. aber auch völlig egal is, wer da wem wann den Lutscher geklaut hat. bzgl Namesraum: Nehmt doch OseaM: dann gäbe es wenigstens zu 100% keine Überschneidungen sondern völlig kontaktfreies nebeneinander-existieren :-P Ich verstehe übrigens nicht, dass sich in dem 3/4 Jahr wo mich das Thema nicht interessiert hat, hier immer noch die gleiche beschissene Grundstimmung is... naja, wird wohl nix zu ändern sein. Konstruktive Grüße Mario Am 15. August 2010 22:39 schrieb Olaf Hannemann ohannem...@gmx.de: Hallo an alle Mitleser, Leider hast Du meine letzten Worte doch nicht verstanden. Ich komme auf Dich zu um einen Termin festzulegen. Hier über die Liste zu posten bringt wirkliche keine Fortschritte. Hab noch etwas Geduld. Dann kriegen wir das schon hin. Mit freundlichen Grüßen Rolf Hi Rolf, wozu immer Termin zum runden Tisch? Wenn OseaM gemeinsamen Konsens anstrebt, müsste man sich einfach den Diskussionen in der OSM-Wiki stellen und nicht einfach imemr im kleinen Kreise irgendwas setzen und da einfach reinhaken. Wie soll ich mich einer gemeinsamen Diskussion stellen, wenn mir immer wieder gesagt wird Das steht jetz nicht zur Diskussion? Ich weis dies kommt nicht von dir, aber ich habe es leider nur allzuoft gelesen. Irgendwann macht man dann halt einfach sein Ding. Daher hier noch einmal meine dringensten Fragen mit der Bitte auf ehrliche Antwort. Warum wurden alle meine seamark=* Tags in seamark=buoy + buoy=* umgewandelt? Wozu braucht man seamark=buoy, wenn doch buoy=* die Kernausage enthält? Komm mir jetzt bitte nicht wieder mit den Flugplätzen und den Beacons. Genau deshalb haben wir seamark:* als Namensraum eingeführt. Dabei ist seamark kein Gütesiegel. Es könnte eben so gut auch nautical oder Hugo heißen. Es ist einfach nur ein Namensraum. Daraus ergibt sich die nächste Frage: Warum ist seamark=buoy + buoy=* einfacher als seamark = *? Ihr sagt ja immer, dass euer Schema so viel einfacher sei. Das seamark:* vor den eigentlichen Tags kann es ja wohl nicht sein. Daran gewöhnt man sich schnell. Warum habt ihr bei den Leuchttürmen alle seamark=landmark tags in seamark=lighthouse umgewandelt? Eine landmark ist eine Landmarke. Dies sind Objekte die von See aus gut zu erkennen sind. Das können z.B. Silos, Hoteltürme (Maritim), Windkraftanlagen oder eben auch Leuchttürme sein. Was willst du mit seamark=lighthouse deutlicher machen? Es gibt doch schon man_made=lighthouse um einen Leuchtturm zu beschreiben. Redundanz? Nebenbei bemerkt diese Änderungen kommen von jemanden, der mir in anderen Mails vorwirft, dass ich ohne seamark:* gar nichts rendern kann. Dies sind nur zwei von vielen Fragen. Ich hoffe, dass wir diese irgendwann einmal unvoreingenommen in einer sachlichen Diskussion klären können. Dazu gehört aber auch, dass man mir (uns*¹) wenigstens zuhört. Noch einmal kurz zur nächsten drängenden Frage warum ich die FT Tags nicht render. Wenn ich sie rendern würde, bräuchte ich kein eigenes Tagging-Schema. Da ich keine eigene Datenbank habe, sondern direkt aus der OSM-Datenbank meine Karten erstelle, bin ich darauf angewiesen, dass die Syntax einigermaßen schlüssig ist. Dies bedeutet z.B. , dass der Name Tag auch den Namen enthält. Dies stelle ich nämlich so auch eins zu eins auf der Karte dar. Wenn dort allerdings etwas wie Tonne rot,grün oder gemessen am *.*.* steht, sieht das wirklich blöd aus. Dies sind leider keine Einzelfälle, sondern schon fast die Mehrheit. Wenn man Dies anmahnt wird einem wie gewohnt das Wort verboten. also habe ich für mich gelernt gar nichts mehr zu sagen und zu warten. Irgendwann wird es wohl auch jemanden anders auffallen. Hat in den letzten Wochen ja auch funktioniert. Also schauen wir mal. Tipp: Ignoriert doch einfach alle seamark:* Tags, sowie ich auch die anderen ignoriere. Lediglich der Editor stellt diese dar um Doppelungen zu vermeiden. Wenn ihr das gleiche tut, gibt es keine weiteren Probleme. just my 2cents Olaf PS. *¹ = Rolf Meyerhof, Peter Schrey, Olaf Hannemann Bin leider in 2 Stunden wieder für eine Woche weg und kann Mails erst wieder ab nächsten Freitag beantworten. Wollte deshalb auch eigentlich erst einmal gar nichts dazu schreiben.
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Am 16. August 2010 02:04 schrieb Stephan Wolff s.wo...@web.de: ... Meine vor gut einem Jahr geäußerten Kritikpunkte am Openseamap-Datenmodell (statt seamark:buoy_cardinal:name besser seamark:name) sind dagegen weiterhin aktuell. Viele Grüße, Stephan am Besten direkt name=* bzw. ref=*. wenn die Lampe ne eigene Referenznummer an halt light:ref=* Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] name für Seezeichen
Am 14. August 2010 03:10 schrieb Stephan Wolff s.wo...@web.de: Hallo Markus! Hallo Stephan, Die Tonne Kiel 3 hat tatsächlich die Beschriftung K3. Ja, Fahrwassertonnen sind meist einheitlich und durchgehend mit einer Abkürzung (Fahrwasser) und einer Zahl (Reihenfolge der Tonnen) bezeichnet, die Steuerbordseite ungerade, die Backbordseite gerade. Zur besseren Lesbarkeit, sowohl auf See als auch auf der Karte, steht ein Leerzeichen zwischen Buchstaben und Zahl: K 3 Auf der Tonne steht K3 (ohne Leerzeichen), in Karten und Texten meist K 3. Man kann entweder die Definition wählen, dass man immer die Beschriftung der Tonne nimmt, oder die Definition, ein Leerzeichen vor der Zahl zu setzen. Keine der beiden Varianten ist selbstverständlich. Betrachtet ihr euer Datenmodell als privates Schema innerhalb von OSM Nein. Aber wir achten darauf, dass der Namensraum seamark: mit der IHO-S-57 übereinstimmt. seid ihr offen für Änderungen und Ergänzungen Klar :-) Das freut mich. mit dem Ziel eines einheitlichen Schemas für Seezeichen? Es gibt weltweit kein besseres und einheitlichers Schema als die S-57. Sie ist aber sehr umfangreich und komplex, und wir freuen uns über fachliche Unterstützung beim Verstehen und beim Umsetzen in die GUI :-) Deine Antwort steht in einem bemerkenswerten Kontrast zu einer Aussage von Jan Jesse in diesem Thread: Allerdings sehe ich eben auch anderes Nutzerverhalten und bin hier wirklich nicht maßgeblich. S-57 ist sicher ein nützliches Vorbild. Allerdings hat OSM andere Basisobjekte, andere Namenskonventionen und historisch andere Tags. Die von OSeaM verwendeten Tags sind von S-57 inspiriert oder daran angelehnt, aber nicht damit identisch. Für sie meisten in S-57 definierten Objekte kenne ich bislang kein OSM-Tag. Markus, hast du einen Vorschlag, mit welchen OSM-Tags man Sperr-, Warn- und Gefahrengebiete sowie Fahrwasser beschreiben sollte? Zudem wird OSM wohl weniger von der Großschifffahrt sondern eher von Schwimmern, Tauchern, Kajakfahrern, Freizeitskippern, Anglern, etc. benutzt. Für diese Gruppen wichtige Objekte fehlen in S-57. Erst müssen wir die in OSM verwendeten Tags definieren, dann kann man über Editorvorlagen und GUIs sprechen. Viele Grüße, Stephan Hallo an Alle, das Wiki-Proposal zum Marine-Tagging ( http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging) orientiert sich doch auch an der S-57? vielleicht sollte man da mit den fleißigen Mappern aus Skandinavien und Übersee eine Lösung diskutieren. Die haben da vielleicht auch andere Ideen/Traditionen in Ihren Namensgebungen von Tonnen und Zeichen. Nicht dass wir eine lokale Lösung schwer erdiskutieren und dann feststellen, dass es international nix taugt ;-) (nebensatz: das proposal is zwar noch im Voting, aber mittlerweile sollte es mit 17(+1)YES zu 1(+1)NO mal langsam als approved gelten. wer könnte das veranlassen?) Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM (ex: name für Seez eichen)
Hi Arne, hi Rest, also der erste Link zum Proposal war der offizielle bzw. öffentliche We der Community Seezeichen zu erfassen. Die anderen Links sind entweder Inhalte der einen oder der anderen überwiegend deutschen Fraktionen (ich glaube das bekommt die restliche Welt garnicht so mit) Ich spreche jetzt mal zur zum Proposal, über die anderen Links können sich die jeweiligen Gruppen äußern. Mir persönlich wäre eine klare Bezeichnung im Link (z.B. OSeaM/Bake-Schema.. etc. dass es sich um Projekt-Unterseiten handelt wichtig, weil sonst wirklich bald kein Aussehnstehender mehr durchblickt... Das Proposal orientiert sich am Schema S57 und versucht die doch sehr kryptischen und eher maschinenorientierten Scheibschemata in eine menschlich lesbare und vor allem in eine einfache, intuitive OSM-STruktur zu wandeln. Ob das gelingt oder nich sollte da diskutiert werden. Bis jetzt scheint was garnicht soo schlechtes bei rumzukommen. Gruß Mario Am 14. August 2010 13:28 schrieb Arne Johannessen a...@thaw.de: Markus wrote: Aber wir achten darauf, dass der Namensraum seamark: mit der IHO-S-57 übereinstimmt. Die S-57 ist die internationale Norm zur Bezeichnung von nautischen Objekten in Seekarten. [...] [...] Es gibt weltweit kein besseres und einheitlichers Schema als die S-57. [...] Ja, also darüber zerbreche ich mir schon seit Monaten den Kopf ... Ich möchte jetzt niemanden hier mit der Geschichte von S-57 langweilen. Aber es dürfte ja auch unumstritten sein, dass die hier zitierten Aussagen über S-57 eigentlich so nicht ganz richtig sind. Dass die folgenden Wiki-Seiten über das Tagging von Seezeichen etc. (zum Glück!) wenig bis gar nichts mit S-57 zu tun haben, ist jedenfalls offensichtlich. http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging http://wiki.openstreetmap.org/wiki/DE:Buoy_Data_Model http://wiki.openstreetmap.org/wiki/DE:Beacon_Data_Model http://wiki.openstreetmap.org/wiki/DE:Lights_Data_Model http://wiki.openstreetmap.org/wiki/DE:Harbour http://wiki.openstreetmap.org/wiki/DE:FreieTonne/Symbole Die oben (etwas aus dem Zusammenhang gerissenen) zitierten Aussagen nehme ich daher zum Anlass, endlich mal nachzufragen, was mit diesen und den im Wiki zu findenden Verweisen auf S-57 eigentlich wirklich gemeint ist? Gefunden habe ich übrigens auch folgende Wiki-Seite, deren OSM-Tags offenbar den Mnemoics bzw. Akronymen aus S-57 entsprechen sollen. Auch diese Seite folgt aber offensichtlich nicht dem Konzept von S-57. Was steckt dahinter? http://wiki.openstreetmap.org/wiki/DE:Bake/S-57 Wäre nett, wenn mich jemand aufklären könnte. Schöne Grüße, Arne (PS: Antworten bitte an talk-de. TIA.) -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bitte betreff benutzen! Re: (kein Betreff) war das seezeichenthema
AssetBurned schrieb: moin On 01.03.2010, at 19:33, Mario Salvini wrote: Mirko Küster schrieb: die Regelung, dass dass die beiden See-Tagging-Schemata bitte friedlich nebeneinander her existieren sollen funktioniert seit einigen Monaten beidseitig richtig gut. Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? Warum nicht wenigstens ein Schema was global läuft, wenn sich das schon direkt auf der OSM DB abspielen muss? Mir fällt keine sinnvolle Begründung ein. ... seamark http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=*%5D = *buoy http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=buoy%5D* (1004), *beacon http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=beacon%5D* (871), *leading http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=leading%5D* (46), *lighthouse http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=lighthouse%5D* (37), *light http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=light%5D* (1) --- das is die Nutzung in Nord Amerika seamark http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=*%5D = *buoy http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=buoy%5D* (3992), *beacon http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=beacon%5D* (617), *lighthouse http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=lighthouse%5D* (118), *dolphin http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=dolphin%5D* (100), *landmark http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=landmark%5D* (66), *anchorage http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=anchorage%5D* (22), --- is die Nutzung in Europa find ich schonmal beeindruckend viel :) du solltest dann aber auch den rest nachschlagen. es geht hier nicht um nord amerika und europa sondern um zwei projekte die in den selben regionen parallel laufen. cu assetburned Hi assetburned, das habe ich gemacht. wollte aber nich so platt wir auskotzen, dass das wiki-schema im vergleich zum oseam-schema auch in Nordamerika (hauptsächlich in den großen seen und rund um San Francisco) benutzt wird. Dass es alleine schon fast 5000Bojen sind find ich sehr cool :) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Mirko Kster schrieb: die Regelung, dass "dass die beiden See-Tagging-Schemata bitte friedlich nebeneinander her existieren sollen" funktioniert seit einigen Monaten beidseitig richtig gut. Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? Warum nicht wenigstens ein Schema was global luft, wenn sich das schon direkt auf der OSM DB abspielen muss? Mir fllt keine sinnvolle Begrndung ein. ... Hi Mirko, hi Rest :-) seamark = buoy (1004), beacon (871), leading (46), lighthouse (37), light (1) --- das is die Nutzung in Nord Amerika seamark = buoy (3992), beacon (617), lighthouse (118), dolphin (100), landmark (66), anchorage (22), --- is die Nutzung in Europa find ich schonmal beeindruckend viel :) Gru Mario (der erst jetzt diesen Handlungsstrang entdeckt hat *g*) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Binnenschifffahrtszeichen
Mirko Küster schrieb: Wie sieht Deine vorläufige Lösung aus (Tags), und kann man sich das schon mal anschauen. Eigentlich sinds ja keine richtigen Zeichen sondern eher kleine Hinweistafeln. So wie ich aber gelesen habe, gibts da garkeine offizielle Form, jedes Land gestaltet die selber. Siehe Anhang. Da steht auf Sachsen Anhaltinischer Seite jeden Kilometer eine kleine Wasser- und Radwegseitige Tafel. Auf Thüringer Seite haben wir noch keine. Ich habe erstmal den Tag für Flusskilomter aus dem Wiki genommen, Kilomterangabe als name und das ganze auf einem Knoten des Flusses. waterway:sign=kilometer name=39 Konkret angewendet hatte ich das erstmal auf einem kleinen Abschnitt hier. http://osm.org/go/0MBeUva Ich warte nur auf offizielle Tags zu eben diesem Problem und den bisher fehlenden Zeichen. Bilder und Standorte des gesamten schiffbaren Teils von Oldisleben bis Naumburg liegen bereits vor. Hätte schon drin sein können. Aber irgendwas ist ja immer. Gruß Mirko wenn du waterway:sign=kilometer + name=... nutzt sollten die Flußkilometer im Grunde in der Freietonne-Karte shon zu sehen sein... http://www.freietonne.de/seekarte/?lat=51.26821lon=11.53423zoom=15layers=B00T wenn man auf die kleinen Kreuze klickt, bekommt man dann den Kilometerstand Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Binnenschifffahrtszeichen
Mirko Küster schrieb: kannst du mir vielleicht mal ein Bild von den Zeichen schicken, die du da meinst? Kann ich mir gerade nix drunter vorstellen (bin aber auch kein Seebär) ;) Im Anhang, Ansonsten schau doch mal, ob du mit dem Onlineeditor auf www.freietonne.de http://www.freietonne.de fündig wirst. Da gibts nichts entsprechendes. Desshalb ja die Frage ob das mit über die Tonnen abgewickelt wird. Da tut auch generell eine besser Doku im Wiki not. Das wäre jedenfalls konstruktiver als sich gegenseitig die Einträge unterm Hintern wegzulöschen. Der Editor ist zwar ansich nicht schlecht, nur mache ich alles generell über JOSM, da man dort auch mal messen und Hilfskonstruktionen setzen kann, womit man eine bessere Lagegenauigkeit der Objekte untereinander erreicht. Pi mal Daumen irgendwohin pinnen ist wie Salami in die Turnhalle werfen. Gruß Mirko wenn einer die entsprechenden Icons malt werden die ganz fix zur Auswahl hinzugefügt. Dann könnte man sie schonmal in der seperaten FT-Datenbank sammeln. Dann ist nur noch die Frage, was wir für Tags den Nodes geben, die dann in die OSM-DB eingetragen werden? Gruß Mario PS: ich nutze eigentlich auch nur JOSM ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Seamark/Marine-Tagging-Proposal open for Voting
http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging. Let's vote or continue discussing critical details. Best Regard Mario ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Seamark/Marine-Tagging-Proposal open for Voting
Hi Sam, man_made=lighthouse tells us something about the physical issue of this building. seamark=lighthouse tells us something about the role as a naval navigation mark. the same problem we have with man_made=beacon. Without any further information nobody can define a use for navigation seamark=beacon (for ships) and airmark=beacon (for aircrafts) can help to give more information here. Sam Vekemans schrieb: Hi, I would think that man_made=lighthouse also needs to be changed so that an additional tag of seamark=lighthouse to show the same thing. as IMO 'seamark' seems to more appropriate ... as a 'land' lighthouse is a 'man_made=tower'. Cheers, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Markus schrieb: ... OpenSeaMap hat sich für einen anderen Weg entschieden: Weil die Beschreibung von nautischen Objekten und Systemen so komplex ist, geben wir uns alle erdenkliche mühe, die Benutzer bestmöglich bei ihrer Arbeit zu unterstützen (ohne dabei Abstriche an der Qualität machen zu müssen). Wir versuchen konsequent in Schichten zu trennen: der Benutzer soll sich nicht mit der Datenschicht befassen müssen. Wir stellen ihnen einen komfortablen Editor zur Verfügung, der das für ihn automatisch erledigt. Amerika is denke ich ein gutes Beispiel, dass diese Sorge unbegründet ist. Dort sind mittlerweile schon fast 1700 Seezeichen manuel mit JOSM erfasst worden. Und der Karten-Output sieht sehr gut aus! siehe Beispiel Erie, am Lake Erie: http://www.freietonne.de/seekarte/index.php?lat=42.1453lon=-80.08056zoom=13layers=B00T (Sorry, dass das jetzt ein Link auf die FT-Karte ist, aber woanders werden die Zeichen leider bis jetzt nicht visualisiert :-) ) Dadurch, dass Du Dein Schema überall im Wiki propagierst, sogar in den Artikeln von OpenSeaMap, ist bei den Benutzern viel Verwirrung entstanden. Einige meinen jetzt sogar, das proposal sei von OpenSeaMap. ich vermute du meinst die Links zum Proposal, die z.B. auf http://wiki.openstreetmap.org/wiki/Marine_Mapping vorhanden sind? Wie du schon geschrieben hast. Eine Wiki ist auch eine Präsentation von gängiger Praxis/aktuellem Wissensstand. Auf einer Seite mit einem so allgemeinen Titel erwarte ich also auch einen Darstellung von allen relevanten Themen zu diesem Schlagwort. Marine Tagging bzw. DE:Segler haben ja auf den 1. Blick Null mit OseaM zu tun. Warum sollen da also nicht 1. alle Projekte die sich mit dem Thema beschäftigen vorgestellt werden und 2. auf das Proposal zum Seezeichen-taggen hingewiesen werden? Wären es kontrete Unterseite von einer Projekt:OseaM-Seite wäre das etwas Anderes, aber so ist das besonders für den Laien erst einmal eine OSM-Wiki-Seite und keine OseaM-Präsentation/Entwicklungshilfe. Die Verwirrung gründet ggf. auch im gewählten Namen. Für einen Außenstehenden wird bestimmt nicht wirklich ein Unterschied zwischen OSM und OseaM sein. Weshalb einige dann auch vermuten das OSM-Proposal sei von OseaM. Etwas umständlich ist, dass es inzwischen drei Datenschemen gibt. Und das auch noch in unterschiedlicher Qualität. Wir haben uns entschieden, vorerst alle drei zu rendern. Zumindest da wo die Struktur und die Qualität einigermassen passt. Drei? welche denn? das OSM-Proposal, die aktuelle und die alte(kryptische) Oseam-Schreibweise? Viel Erfolg auf der Boot und hoffentlich nicht erst bis Ende Januar ;-) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Markus schrieb: ... OpenSeaMap hat sich für einen anderen Weg entschieden: Weil die Beschreibung von nautischen Objekten und Systemen so komplex ist, geben wir uns alle erdenkliche mühe, die Benutzer bestmöglich bei ihrer Arbeit zu unterstützen (ohne dabei Abstriche an der Qualität machen zu müssen). Wir versuchen konsequent in Schichten zu trennen: der Benutzer soll sich nicht mit der Datenschicht befassen müssen. Wir stellen ihnen einen komfortablen Editor zur Verfügung, der das für ihn automatisch erledigt. Amerika is denke ich ein gutes Beispiel, dass diese Sorge unbegründet ist. Dort sind mittlerweile schon fast 1700 Seezeichen manuel mit JOSM erfasst worden. Und der Karten-Output sieht sehr gut aus! siehe Beispiel Erie, am Lake Erie: http://www.freietonne.de/seekarte/index.php?lat=42.1453lon=-80.08056zoom=13layers=B00T (Sorry, dass das jetzt ein Link auf die FT-Karte ist, aber woanders werden die Zeichen leider bis jetzt nicht visualisiert :-) ) Dadurch, dass Du Dein Schema überall im Wiki propagierst, sogar in den Artikeln von OpenSeaMap, ist bei den Benutzern viel Verwirrung entstanden. Einige meinen jetzt sogar, das proposal sei von OpenSeaMap. ich vermute du meinst die Links zum Proposal, die z.B. auf http://wiki.openstreetmap.org/wiki/Marine_Mapping vorhanden sind? Wie du schon geschrieben hast. Eine Wiki ist auch eine Präsentation von gängiger Praxis/aktuellem Wissensstand. Auf einer Seite mit einem so allgemeinen Titel erwarte ich also auch einen Darstellung von allen relevanten Themen zu diesem Schlagwort. Marine Tagging bzw. DE:Segler haben ja auf den 1. Blick Null mit OseaM zu tun. Warum sollen da also nicht 1. alle Projekte die sich mit dem Thema beschäftigen vorgestellt werden und 2. auf das Proposal zum Seezeichen-taggen hingewiesen werden? Wären es kontrete Unterseite von einer Projekt:OseaM-Seite wäre das etwas Anderes, aber so ist das besonders für den Laien erst einmal eine OSM-Wiki-Seite und keine OseaM-Präsentation/Entwicklungshilfe. Die Verwirrung gründet ggf. auch im gewählten Namen. Für einen Außenstehenden wird bestimmt nicht wirklich ein Unterschied zwischen OSM und OseaM sein. Weshalb einige dann auch vermuten das OSM-Proposal sei von OseaM. Etwas umständlich ist, dass es inzwischen drei Datenschemen gibt. Und das auch noch in unterschiedlicher Qualität. Wir haben uns entschieden, vorerst alle drei zu rendern. Zumindest da wo die Struktur und die Qualität einigermassen passt. Drei? welche denn? das OSM-Proposal, die aktuelle und die alte(kryptische) Oseam-Schreibweise? Viel Erfolg auf der Boot und hoffentlich nicht erst bis Ende Januar ;-) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Nehmen wir mal die Ansteuertonne von Rostock als Beispiel: *OpenSeaMap-Tags* seamark:topmark:shape=sphere seamark:topmark:colour=red seamark:radar_reflector=yes seamark:name=Rostock seamark:lon=012 seamark:light:signal:period=4 seamark:light:ref=LF-Nr 3448 seamark:light:colour=white seamark:light:character=Iso seamark:lat=54 seamark:category=major seamark:buoy_safewater:shape=pillar seamark:buoy_safewater:colour:pattern=vertical_stripes seamark:buoy_safewater:colour=white; red seamark:buoy_safe_water:shape=pillar note=Ansteuertonne Warnemünde * OSM-Schema-Tags (nach WIKI)* seamark=buoy buoy=safe_water topmark=yes topmark:shape=sphere topmark:colour=red radar_reflector=yes name=Rostock light=yes light:signal_period=4 light:ref=LF-Nr 3448 light:colour=white light:character=Iso buoy:category=major buoy:shape=pillar buoy:colour_pattern=vertical_stripes buoy:colour=white; red buoy:shape=pillar note=Ansteuertonne Warnemünde Und so soll das dann denmächst, für alle SeeZeichen aussehen? da blickt doch zum 1. Keiner mehr auf Dauer durch und zum 2. is der Pflegeaufwand enorm, weil doppelt so groß. Mal davon abgesehen dass es bis auf Nuance redundante Infos sind. Wenn jetzt einer auf die Idee käme allen Ways mit highway= ein neues System einzuführen ala way:street=primary und das überall einpflegen würde, ansonsten aber identische Values nehmen würde, wäre das dann auch allerseits verständlich und akzeptiert, oder würde man sich über die völlig unnötige Redundanz wundern? Gruß Mario Frederik Ramm schrieb: Hallo, Jan Jesse wrote: Das gegenwärtige Tagging-Schema ist nebenbei nicht Produkt der FreieTonne, es wurde im Wiki entwickelt, und wir haben es übernommen. Weil eben kein anderes da war. Ich hab mir mal hier diesen einen Node exemplarisch angeschaut: http://osm.mapki.com/history/node.php?id=359756831 Da sieht man, dass es kaum Loeschungen gab, es kam staendig was hinzu; am Schluss hat Markus einmal selbst seine alten grossgeschriebenen Tags geloescht und kleingeschriebene hingemacht, und dann hat der User freietonne-db einen Namen und Link hinzugefuegt und bei einigen Tags das seamark:... entfernt. Zunaechst einmal will ich anmerken, dass ich dieses hierarchische Tagging nach Art von natur=baum; natur:baum:typ=birke; natur_baum_birke_hoehe=30m, das von OpenSeaMap hier betrieben wird, fuer (a) OSM-untypisch und (b) unnoetig klobig halte. ABER - und ich beziehe mich da nur auf das Beispiel von diesem einen Node - das ist doch kein Grund, denen ihre Tags zu loeschen. Einfach Eure eigenen dazu, fertig - Waffenstillstand, wie Ulf sagt. Oder noch besser, Eure Software so bauen, dass sie ggf. auch die OpenSeaMap-Tags versteht. Das ist ja nun wirklich kein Hexenwerk. Ich habe jeden Eintrag händisch geprüft, und keine Information gelöscht. Das mache ich fast täglich, und es sollte in Ordnung gehen. Wir führen übrigens auch die History zu jedem Eintrag, eliminieren Dopplungen usw. Jeder mag prüfen, ob das so geht. In diesem Fall ist zwar keine *Information* geloescht worden, aber es wurden Tags geloescht. Wie oben geschrieben, ich bin auch der Ansicht, dass das Schema, dass sich OpenSeaMap da ausgedacht hat, komisch ist, aber warum deswegen streiten? Gerade weil deren Tags alle diese Prefixe haben, sind sie doch *sehr* leicht zu erkennen und im Zeifel auch zu ignorieren. Dann macht man noch ein Kontrolltool, das alle Nodes, die dual getaggt sind, prueft, ob beide Taggingwelten auch das gleiche aussagen - und damit kann man doch arbeiten. Irgendwann wird sich das ganze schon glaetten, aber wieso sollte jetzt in diesem fruehen Stadium der Elan einer der beiden Seiten durch sowas aetzendes wie eine ewige Tagging- diskussion gebremst werden? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Markus schrieb: ... 1.) Warum halten sich die seamark:-Vertreter so vornehm aus der Diskussion/ Arbeit am Tagging Schema raus? Hm - vielleicht erinnerst Du Dich noch daran, dass /Du/ es warst, der uns gefragt hat, wie denn OSM und unser Datenschema für OpenSeaMap funktioniert? Und dass /wir/ Dir mit viel persönlichem Engagement versucht haben, Deine Fragen zu beantworten und das System zu erklären? Und sogar ganz praktisch auf Deinem Server mitgeholfen hatten, als Ihr Schwierigkeiten beim Umsetzen hattet? momentan hat euer eigenbrödlerisches Verhalten bzw. eure no-information-policy (geht ja schon seit Monaten so) nich wirklich viel mit OSM zu tun. OSM lebt von der Bündelung von Man-Power und Ideen(dazu is die Wiki ja z.B. da). Echt Schade. Wenn Du nun trotzdem eigene Wege gehen willst, dann tue es. Aber erwarte nicht, dass wir Dir auch folgen. Und bitte tue es ohne uns zu behindern. soweit ich das von außen beurteilen kann hat Freietonne kein eigenes Schema, sondern erkennt sowohl euer Schema als auch das in der OSM-Wiki entworfene Schema. Ein eigener Weg is eher das was OseaM macht. 2.) Wofür wird der Präfix seamark: tatsächlich benötigt, welchen Vorteil bringt seine Benutzung? Wir kennzeichnen damit nautische Informationen. Und dass diese einen erhöhten Qualitätslevel erfüllen. seamark:buoy_lateral:color=red erfüllt also einen höheren Qualitätslevel, als buoy:colour=red (buoy=lateral_port) ? glaubst du nicht wirklich, oder? Wenn doch, erklärs mir bitte nochmal, den ich sehe keinen Mehrwert. - - - - Ich hoffe, dass jetzt alles zumindest soweit geklärt ist, dass Du künftig eigenmächtige Löschungen und Änderungen unterlässt. Damit wir uns wieder unserer Arbeit und in diesen Thread wieder dem eigentlichen Thema zuwenden können. wünschenwert wäre die Teilnahme an der öffentlich geführten Diskussion (z.B. in der Wiki) damit Synergien entstehen anstatt an einander vorbei zu arbeiten. Danke für Dein Verständnis, Markus PS: Für Diskussionen über Daten und Datenschemen stehen wir nach der boot wieder zur Verfügung. boot 2011? (mehr als Joke zu sehen, aber die Frage drängt sich igendwie auf, bei der Anteilnahme z.B. am Proposal im Web, sorry *g*) Produktive Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Nop schrieb: Hi! Genießt nun das seamark:-Schema einen Sonderstatus? Nein, die seamark:-Tags sind genau wie alle anderen auch. Es sollten grundsätzlich keine unbekannten Tags ohne Rückfrage einfach gelöscht werden. Und erst recht nicht, wenn Dir bewußt ist, daß sie jemand pflegt, benutzt und rendert. Ein solches Verhalten wird je nach Geschmack als schlechter Stil, Edit War oder Vandalismus verstanden. Das gilt für alle Tags, auch für solche für die Du selbst lieber eine Alternative benutzt. Dort, wo deren traditionellen Testbereiche liegen (Häfen Rostock, Kiel, Fehmarn), ändere ich die Daten i.d.R. nicht. Eben weil ich weiß, daß dort getestet wird. Z.B. auf Fehmarn haben wir unsere Tonnen sogar gelöscht, um Platz zu machen :-) Deine Haltung verstehe ich nicht. Es ist nicht nötig Platz zu machen. Es gibt keine Konflikte. Werte aus, was Deinem Tagging-Schema entspricht und ignoriere alles, was Deinem Tagging-Schema nicht entspricht. So einfach ist das. Ansonsten glaube ich aber, daß ein Standard anzustreben ist. Und da gehört ein wenig Datenpflege dazu. Du wirst keinen Standard durchsetzen können, indem Du täglich alles weglöscht, was nicht Deinem Standard entspricht. bye Nop Hi Nop, es geht doch garnicht darum ob was gelöscht wird, oder nicht. Es geht mehr darum, gemeinsam OSM voranzutreiben. In der OSM-Wiki gibts ein Proposal, was genau dass versucht (mit einiger Beteiligung aus Skandinavien, Deutschland und USA). Leute von OseamM beteiligen sich , trotz mehrfachem Bitten, bis jetzt leider nicht daran, wobei Sie echt gute Unterstützung geben könnten. Das is im Grunde der Punkt, denn ich nicht verstehe. Klar hat jeder das Recht in seinem Kämmerlein was eigenes zu machen, aber wenn doch schon eine öffentliche Diskussion dazu läuft und man dazu eingeladen wird, warum beteiligt man sich dann nicht dran? Ich will da auch garnicht immer so drauf rumreiten, aber ich kanns halt leider einfach ncht nachvollziehen. Liebe Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsseld orf
Martin Koppenhoefer schrieb: Am 10. November 2009 17:52 schrieb Mario Salvini salv...@t-online.de mailto:salv...@t-online.de: momentan hat euer eigenbrödlerisches Verhalten bzw. eure no-information-policy (geht ja schon seit Monaten so) nich wirklich viel mit OSM zu tun. OSM lebt von der Bündelung von Man-Power und Ideen(dazu is die Wiki ja z.B. da). Echt Schade. ja, das Wiki ist dazu da, allerdings ist niemand verpflichtet, es auch zu nutzen. soweit ich das von außen beurteilen kann hat Freietonne kein eigenes Schema, sondern erkennt sowohl euer Schema als auch das in der OSM-Wiki entworfene Schema. Ein eigener Weg is eher das was OseaM macht. ein eigener Weg ist jedenfalls legitim, und kein Grund, die Tags zu löschen. Wie weiter oben hier auch schon geschrieben wurde: Tags von anderen wider besseres Wissen zu löschen ist Vandalismus. Gruß Martin da stimme ich zu. aber wie gesagt. es geht hier nicht um die Löschung von Tags, sondern um den Wunsch an einem Strang zu ziehen. 2 Schemata die zu 98% resundant sind parallel zu Nutzen kann auf jeden Fall nicht der allgemeine Wunsch sein (was nichts damit zu tun hat, dass man es so machen könnte). Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Olaf Hannemann schrieb: Hallo Mario, an dieser Stelle möchte ich einmal kurz zu den vorgebrachten Fragen von dir und Jan antworten. es geht doch garnicht darum ob was gelöscht wird, oder nicht. Doch geht es. Es geht mehr darum, gemeinsam OSM voranzutreiben. Wenn 'gemeinsam' bedeutet, dass alle anderen Meinungen gelöscht werden, möchte ich gar nichts 'gemeinsam' voranbringen. ;-) In der OSM-Wiki gibts ein Proposal, was genau dass versucht (mit einiger Beteiligung aus Skandinavien, Deutschland und USA). Leute von OseamM beteiligen sich , trotz mehrfachem Bitten, bis jetzt leider nicht daran, wobei Sie echt gute Unterstützung geben könnten. Das is im Grunde der Punkt, denn ich nicht verstehe. Warum ich persönlich mich nicht daran beteilige, sollte dir eigentlich relativ klar sein. Ich wurde immerhin während der letzten Diskussion direkt dazu aufgefordert. Stichwort An der Stelle ist also keine Verhandlungsmasse, siehe die Diskussion auf FT-Talk: http://www.freietonne.de/pipermail/talk/2009/000116.html Wenn es keine Verhandlungsmasse gibt, worüber wollen wir denn diskutieren? Es ist mir bis heute nicht gelungen eine Antwort auf meine damalige Frage, wozu ihr den Schlüssel seamark=buoy braucht, zu bekommen. So what? Ist doch egal. Aber wundert euch dann bitte nicht wenn wir irgendwann unser eigenes Ding machen. Ich möchte an dieser Stelle auch gleich ein paar weitere Fragen aus dem Ft- Thread klären: 1. Warum benutzen wir nicht den Ft-Importfilter? Da wir die Daten direkt in die OSM-db schreiben und aus dieser auch wieder rendern (osmarender/or p), ist dieser für uns unbrauchbar. Wenn ich direkt aus der OSM-db render, ist es für mich wichtig, dass 99% der Einträge auch nach einer Änderung des Schemas noch die alten Schlüssel aufweisen, sonst hätte ich von jetzt auf gleich keine Seezeichen mehr auf der Karte bis ich den Renderer angepasst habe. 2. seamark:* ist keine Redundanz, sondern ein Namensraum. Da wir z.B. bei Leuchttürmen unsere Daten an den bestehenden Knoten anhängen, muss es eine Unterscheidung zwischen See und Land geben, sonst wüsste irgendwann niemand mehr was gemeint ist. Siehe die Regattafelder in Kiel: http://www.openstreetmap.org/?lat=54.4293lon=10.2078zoom=14layers=B000FTF Müssen diese ganzen Namen ständig sichtbar sein? (Ich weiß wir taggen nicht für die Renderer) Klar hat jeder das Recht in seinem Kämmerlein was eigenes zu machen, aber wenn doch schon eine öffentliche Diskussion dazu läuft und man dazu eingeladen wird, warum beteiligt man sich dann nicht dran? Siehe oben. Ich will da auch garnicht immer so drauf rumreiten, aber ich kanns halt leider einfach ncht nachvollziehen. Ich hoffe, dass ich dir ein wenig dabei geholfen habe ;-) Beste Grüße Olaf warum bezieht ihr euch eigentlich immmer auf FreieTonne? die hat hier doch garnix zu suchen. Ich fänds schön, wenn mal neben dem FTvsOSeaM gebrabbel auchmal über das eigentliche Tthema geschrieben werden könnte. Das Proposal in der OSM-Wiki hat auf jeden Fall nix mit FT zu tun. Dass die das nutzen (genau wie sie übrigens auch das OseaM-Muster nutzen) hat ja überhaupt nix damit zu tun. zu deiner Frage: seamark= *buoy http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=buoy%5D* (3158), *beacon http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=beacon%5D* (713), *dolphin http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=dolphin%5D* (88), *lighthouse http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=lighthouse%5D* (77), *landmark http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=landmark%5D* (31), *perch http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=perch%5D* (16),... nur ein paar Values die klar sogar für jeden Laien etwas aussagen. beacon=* alleine ist dagegen nicht eindeutig, weil es schließlich auch Beacons auf Flughäfen gibt. Also bedarf es dem seamark=beacon zur eindeutigen Zuordnung. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Olaf Hannemann schrieb: Hallo Mario, seamark= *buoy http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=buoy%5D* (3158), *beacon http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=beacon%5D* (713), *dolphin http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=dolphin%5D* (88), *lighthouse http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=lighthouse%5D* (77), *landmark http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=landmark%5D* (31), *perch http://tagwatch.stoecker.eu/osmxapi/*%5Bseamark=perch%5D* (16),... nur ein paar Values die klar sogar für jeden Laien etwas aussagen. beacon=* alleine ist dagegen nicht eindeutig, weil es schließlich auch Beacons auf Flughäfen gibt. Also bedarf es dem seamark=beacon zur eindeutigen Zuordnung. Was hat Tagwatch mit der Sinnhaftigkeit dieses Schlüssels zu tun? Vor allem wenn er per Bot eingefügt wird? wozu braucht ihr ihn? Olaf Hi Olaf was wird per Bot eingefügt? ich würde behaupten, die wenigsten Tags sind da automatisch eingefügt worden und die meisten wohl nichtmal über FT, sondern über JOSM. Diese leeren Vorwürfe die ihr euch gegenseitig an den Kopf werft sind echt langweilig auf Dauer... Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Nop schrieb: Hi! Mario Salvini schrieb: es geht doch garnicht darum ob was gelöscht wird, oder nicht. Doch. Es geht ausschließlich um das Löschen von fremden Daten. nein geht es nicht. denn wir sind uns einig, dass fremde Tags löschen böse ist und die, die es gemacht haben haben dass spätestens nach dieser Diskussion auch verstanden. Mit dem OSM-Schema-Proposal hat das aber nix zu tun. Es geht mehr darum, gemeinsam OSM voranzutreiben. In der OSM-Wiki gibts ein Proposal, was genau dass versucht (mit einiger Beteiligung aus Skandinavien, Deutschland und USA). Leute von OseamM beteiligen sich , trotz mehrfachem Bitten, bis jetzt leider nicht daran, wobei Sie echt gute Unterstützung geben könnten. Dafür wird es wohl Gründe geben, aber das tut alles nichts zur Sache. Es geht einzig und allein darum, daß jeder ein alternatives Tagging-Schema ausprobieren darf, wenn er dabei nichts Bestehendes kaputt macht. Egal ob es da schon was gibt und egal was im Wiki steht und egal warum er es benutzen will. Alternativen Ansätzen täglich ihre Tags zu löschen ist eine merkwürdige Auffassung von gemeinsam OSM voranzutreiben. bye Nop im Grunde sind wir da d'accord. Aber gibts denn einen Grund von den OseaM-Leute warum sich keiner wirklich mit dem offenen Proposal in der Wiki befasst? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Nop schrieb: Hi! Und so soll das dann denmächst, für alle SeeZeichen aussehen? da blickt doch zum 1. Keiner mehr auf Dauer durch und zum 2. is der Pflegeaufwand enorm, weil doppelt so groß. Yep, ist unübersichtlich, aber wenn Ihr Euch nicht auf ein gemeinsames Tagging-Schema einigen könnt, dann gibt es eben erst mal zwei Sätze an Tags. Der Aufwand steigt dabei nicht, es kann sich ja jeder raussuchen, welchen Satz er pflegt oder ob er beide nimmt. Auf jeden Fall kein Grund, einfach Tags wegzulöschen, die andere Leute pflegen und benutzen wollen. Du willst schließlich auch nicht, daß man zum Aufräumen Deine Version der Tags löscht, oder? Ignorier sie einfach und alles ist in Ordnung. Wenn jetzt einer auf die Idee käme allen Ways mit highway= ein neues System einzuführen ala way:street=primary und das überall einpflegen würde, ansonsten aber identische Values nehmen würde, wäre das dann auch allerseits verständlich und akzeptiert, oder würde man sich über die völlig unnötige Redundanz wundern? Man würde sich wundern - und die Tags ignorieren. Übrigens ein gutes Beispiel, es gibt solche alternativen Highway-Tags tatsächlich. Schau mal in Tagwatch, da wirst Du zahlreiche Tags nach dem Schema highway:plan.at:* finden. Sie gehören zu einem Import, mit dem die meisten Mapper nix am Hut haben, aber stören die normalen highways nicht, alle ignorieren sie und erstaunlicherweise gibt es überhaupt kein Problem mit denen. bye Nop Hi Nop, es geht doch garnicht darum ob was gelöscht wird, oder nicht. Es geht mehr darum, gemeinsam OSM voranzutreiben. In der OSM-Wiki gibts ein Proposal, was genau dass versucht (mit einiger Beteiligung aus Skandinavien, Deutschland und USA). Leute von OseamM beteiligen sich , trotz mehrfachem Bitten, bis jetzt leider nicht daran, wobei Sie echt gute Unterstützung geben könnten. Das is im Grunde der Punkt, denn ich nicht verstehe. Klar hat jeder das Recht in seinem Kämmerlein was eigenes zu machen, aber wenn doch schon eine öffentliche Diskussion dazu läuft und man dazu eingeladen wird, warum beteiligt man sich dann nicht dran? Ich will da auch garnicht immer so drauf rumreiten, aber ich kanns halt leider einfach ncht nachvollziehen. Liebe Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Nop schrieb: Hi! Mario Salvini schrieb: es geht doch garnicht darum ob was gelöscht wird, oder nicht. Doch. Es geht ausschließlich um das Löschen von fremden Daten. nein geht es nicht. denn wir sind uns einig, dass fremde Tags löschen böse ist und die, die es gemacht haben haben dass spätestens nach dieser Diskussion auch verstanden. Mit dem OSM-Schema-Proposal hat das aber nix zu tun. Es geht mehr darum, gemeinsam OSM voranzutreiben. In der OSM-Wiki gibts ein Proposal, was genau dass versucht (mit einiger Beteiligung aus Skandinavien, Deutschland und USA). Leute von OseamM beteiligen sich , trotz mehrfachem Bitten, bis jetzt leider nicht daran, wobei Sie echt gute Unterstützung geben könnten. Dafür wird es wohl Gründe geben, aber das tut alles nichts zur Sache. Es geht einzig und allein darum, daß jeder ein alternatives Tagging-Schema ausprobieren darf, wenn er dabei nichts Bestehendes kaputt macht. Egal ob es da schon was gibt und egal was im Wiki steht und egal warum er es benutzen will. Alternativen Ansätzen täglich ihre Tags zu löschen ist eine merkwürdige Auffassung von gemeinsam OSM voranzutreiben. bye Nop im Grunde sind wir da dakor. Aber gibts denn einen Grund aus der OseaM-Leute warum sich keiner wirklich mit dem offenen Proposal in der Wiki befasst? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Nop schrieb: Hi! Mario Salvini schrieb: es geht doch garnicht darum ob was gelöscht wird, oder nicht. Doch. Es geht ausschließlich um das Löschen von fremden Daten. nein geht es nicht. denn wir sind uns einig, dass fremde Tags löschen böse ist und die, die es gemacht haben haben dass spätestens nach dieser Diskussion auch verstanden. Mit dem OSM-Schema-Proposal hat das aber nix zu tun. Es geht mehr darum, gemeinsam OSM voranzutreiben. In der OSM-Wiki gibts ein Proposal, was genau dass versucht (mit einiger Beteiligung aus Skandinavien, Deutschland und USA). Leute von OseamM beteiligen sich , trotz mehrfachem Bitten, bis jetzt leider nicht daran, wobei Sie echt gute Unterstützung geben könnten. Dafür wird es wohl Gründe geben, aber das tut alles nichts zur Sache. Es geht einzig und allein darum, daß jeder ein alternatives Tagging-Schema ausprobieren darf, wenn er dabei nichts Bestehendes kaputt macht. Egal ob es da schon was gibt und egal was im Wiki steht und egal warum er es benutzen will. Alternativen Ansätzen täglich ihre Tags zu löschen ist eine merkwürdige Auffassung von gemeinsam OSM voranzutreiben. bye Nop im Grunde sind wir da dakor. Aber gibts denn einen Grund von den OseaM-Leute warum sich keiner wirklich mit dem offenen Proposal in der Wiki befasst? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Frederik Ramm schrieb: Hallo, Mario Salvini wrote: Nehmen wir mal die Ansteuertonne von Rostock als Beispiel: Und so soll das dann denmächst, für alle SeeZeichen aussehen? da blickt doch zum 1. Keiner mehr auf Dauer durch und zum 2. is der Pflegeaufwand enorm, weil doppelt so groß. Beide Schemata sind fuer sich genommen schon fuer den Menschen praktisch unhandhabbar (wegen der Vielzahl der Tags - niemand kann sich das alles merken und nicht staendig was vergessen oder verwechseln). Insofern spielt es keine Rolle, ob jetzt nochmal so viel Tags dazu kommen. Ihr habt Euch da alle beide eine Welt zusammengebastelt, in der man nur noch mit Eurer jeweiligen Spezialsoftware taggen kann, also stellt Euch nicht so an und spendiert der jeweiligen Spezialsoftware halt das Wissen ueber die Tags der Gegenseite. Bye Frederik Wenn Herr Schmitz-Müller am Ufer steht und ein schwimmendes Rotes Ding sieht taggt er sie einfach als: *seamark=buoy* *buoy:color=red* , fertig. wenn sie dann noch eine Licht hat setzt er noch *light=yes*. Mit ziemlicher Sicherheit ird das Zeichen dann sogar korrekt angezeigt. Is das wirklich so kompliziert? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düss eldorf
Hi Markus, du engagierst dich ja sehr. Das finde ich gut. Nur komischerweise nicht wirklich in dem für OSM essentiellen Diskussionsebenen. (vornweg die WIKI!) Bevor du also auf einer Messe irgendwelche Banner hochhälst, beteilige dich doch bitte auch am normalen Meinungsbildungsprozess auf diesen Systemebenen. Unter http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging wartet man leider bis heute auf konstruktive Teilnahme deinerseits. Das finde ich echt Schade. Ich würde mir weniger Lobbyarbeit und mehr Informationsaustausch wünschen. Konstruktive Grüße Mario Markus schrieb: OpenSeaMap wird auf der boot in Düsseldorf präsentieren: www.boot.de 23.-31.1.2010 Halle 14, Stand G 39 Die boot ist mit 240.000 Besuchern und 1600 Ausstellern eine der grössten und wichtigsten Messen in Europa zum Thema Wassersport. Und wahrscheinlich eine der grössten Messen, auf denen OSM bisher vertreten war. Entsprechend anspruchsvoll ist die Herausforderung. Die Besucher bilden eine potentiell neue Benutzergruppe für OSM: Alle kennen sich aus mit Navigation, mit Karten, Koordinaten und GPS. Alle können ein GPS bedienen und wissen, wie man Tracks aufzeichnet. Die meisten besitzen ein eigenes Hand-GPS. Und sie kommen alle sehr viel rum in der Welt. Sie werden an unserem Stand OSM kennenlernen. Natürlich zielgruppengemäss als Seekarte: www.OpenSeaMap.org - die freie Seekarte Wir zeigen die Aktualität von OSM anhand der Slippymap. Fehlende Objekte können gleich am Stand eingetragen werden. In der Kartenwerkstatt bieten wir mehrere JOSM-Arbeitsplätze. In interaktiven Präsentationen können die Besucher die Geschichte von OSM kennenlernen, die Entwicklung der Community und der Datenbank, verschiedenen Spezialkarten ausprobieren, von der Rad- über die OPNV- bis zur Wanderkarte, und natürlich die Möglichkeiten der Seekarte kennenlernen. Es wird Tutorials geben zum mappen und zur Arbeit mit den Editoren, und natürlich wie man Karten nutzt und auf Geräten installiert. Wir haben einen Vortragsraum zur Verfügung, wo wir regelmässig ausgewählte Themen präsentieren. Und natürlich ist die boot Treffpunkt für alle OSMer aus nah und fern, zum Fachsimpeln, Erfahrungsaustausch, Klönen und Pläne schmieden. Soweit unser Konzept. Du bist herzlich eingeladen! Als Besucher und als Mitmacher. Vielleicht hast Du Lust, das Flair dieser Messe als Standbetreuer zu erleben? Oder vielleicht hast Du eine Präsentation, die Du schon mal woanders erfolgreich vorgeführt hast und die Du mitbringst oder zur Verfügung stellen willst? Oder vielleicht magst Du eine Präsentation erstellen? oder einen Screencast? oder ein Video drehen? Oder Du möchtest einen Vortrag halten? über OSM? über Kartografie? über Navigation? über Opensource? Oder Du hast Lust, einen (oder mehrere) Tage als Mentor in der Karten-Werkstatt Interessierte beim Kartografieren zu unterstützen? Wenn Du Lust oder eine Idee hast, ruf mich an. Mit herzlichem Gruss, Markus +49-9155-1715 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap - Entwicklerwochenende in N ürnberg
Das hört sich vielversprechend an. Vielleicht könnt ihr ja nun auch in der OSM-Wiki unter http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging das Proposal mit vorantreiben. :-) Produktive Grüße Mario Markus schrieb: Das Wochenende ist super gelaufen. Waren intensive Tage mit interessanten und wirklich kompetenten und engagierten Menschen aus nah und fern. Hat ein bisschen an das Treffen im Linuxhaus erinnert: Wir haben bis spät in die Nacht gearbeitet und geklönt, einige auch bis in den frühen Morgen. Spannende Ideen, zukunftsträchtige Visionen, klare Ziele, konkrete Pläne und Aufgaben, vielversprechende Kooperationen und immer wieder beeindruckende Ergebnisse, und manche Lösung ist im Traum aufgetaucht und wurde gleich nach dem Aufwachen umgesetzt. Ein richtig tolles Projekt! Selbstverständlich werden wir berichten, sobald es neue konkrete Ergebnisse gibt (siehe nächste Mail). Herzlichen Dank allen die dabei waren! Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] [tagging] alley - for tree-lined roads?
tree_lined=yes Robert schrieb: Hello, We are discussing in talk-de (German board) just streets and other ways with many trees nearby. I found here: http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/tree_row alley=left/right/both I think the tag “alley” is a mistranslation (false friends) and 1. avenue or 2. tree-lined road is better for roads marked by trees. The tag alley is already used for highway=service; service=alley for narrow ways. I think the second version “tree-lined” or ”tree_lined” is better than “avenue”. With this key we can use it for other lines of trees, for example near railways, rivers and so on. At the moment this tag is probably only mainly used in Germany: http://osmdoc.com/de/tag/alley/#values comparison: http://tagwatch.stoecker.eu/Germany/De/tags.html key alley with values: both (251), right (27), left (26), yes (8) My questions: Would we like to change this tag? Robert ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Buslinien Bahnhof
Tobias Wendorff schrieb: Hallo, Dimitri Junker schrieb: Oxomoa bestätigt, daß er derzeit aus Zeitmangel nicht an der Weiterentwicklung des ÖPNV-Schemas arbeitet und den aktuellen Stand auch nicht verfolgt. AFAIK arbeiten den Engländer gerade aktiv an einem eigenen oder an einer Erweiterung des Schemas, da dort ein großer Import vor der Tür steht. Es gibt auch eine eigene Mailinglist... Das deutsche Schema halte ich in einigen Bereichen für suboptimal, aber das passiert häufig, wenn solche Konzepte hinter verschlossener Tür entwickelt werden. Grüße Tobias hast du ne genaue Ahnung wo genau? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buslinien Bahnhof
Dimitri Junker schrieb: Hallo, Für den Passagier zählt sowieso erstmal die Fläche Bahnsteig und wo da nun ein Punkt ist, spielt so erstmal keine Rolle. Da sind wir uns ja vollkommen einig. Bei Mario schien es aber so als ob er den Haltepunkt ganz weglassen wollte weil er eh ungenau wäre. für den Passagierverkehr ist diese Position auch im Grunde nicht wichtig. Aber bevor wir vielleicht mit unterschiedliche Konzepten im Hinterkopf über einen Lösungsansatz schreiben empfehle ich einfach mal in das IFOPT-Pdf zu schauen: http://www.naptan.org.uk/ifopt/ifoptV1.0-36/CENTC278WG3SG6_IFOPT_20081110_36.pdf Auf Seite 42 und 43 ist eine schöne schematische Zechnung wie man einen Bahnhof erfassen könnte. Die VehicleStopping Position kommt unserem Haltepunkt gleich. Statt Plattform nennen die es da Quay (vermutlich aus Tradition) Interessant aus Passagiersicht könnten die BoardingPositions sein. Aber dafür is die DB wohl wirklich zu ungenau ;) Nach diesem Prinzip könnten wir echt von der Eingangstür bis in den Waggon routen. Aus den realen Punkten hast du aber beispielsweise die Möglichkeit zusammen mit Wagenstandspländen die Standorte der eizelnen Wagen und bis zu einem gewissen Teil sogar deren Türen zu verorten. Wann bist Du zuletzt mit der DB gefahren? Meine erfahrung ist, daß der Zug durchschnittlich 2 Wagenlängen falsch hält. Eine Möglichkeit wäre sich an den Fahrplänen zu orientieren. Wenn dort z.B. Gleis 3 für lange Züge oder 3a/b und 3c/d für kurze steht könnte man überlegen entsprechend 3 Platforms einzuzeichnen. Ich glaube Mirko tut das ziemlich oft ;) Apmzf, ABpmz, WRmz, Bpmz, Bpmz, Bpmbz, Bpmzf. Ah ja. über eine Aufschlüsselung der Abkürzung würde ich mich auch freuen :) Aber was solls, wir haben ja in der neuen Methode eh Haltepunkt und Platform, da kann man ja ersteres dahin setzen wo die Haltetafel ist und letzteres do wo man es für den Passagier für sinnvoll hält, bzw direkt als Fläche. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buslinien Bahnhof
Frederik Ramm schrieb: Hallo, Mario Salvini wrote: Die VehicleStopping Position kommt unserem Haltepunkt gleich. Statt Plattform nennen die es da Quay (vermutlich aus Tradition) Mir wurde erklaert, dass man Quay genommen hat, weil alle anderen in Frage kommenden Begriffe schon in einem der diversen anderen Standards verbrannt wurden und die Teilnehmer dann immer schon ein bestimmtes Konzept im Kopf hatten - Quay war fuer alle gleich ungewoehnlich ;-) Bye Frederik oder eben so ;-) Persönlich find ich Quay aber garnicht so schlecht. Schließlich kann man ihn mit QuayType blitzschnell spezifizieren: Vehicle Mode - StopPlaceType - QuayType - BoardingPositionType air - airport - airlineGate - doorFromAirlineGate rail - railStation - railPlatform - positionOnRailPlatform ... bus - busStation - busStop - positionAtBusStop bus - onStreetBus - busStop - positionAtBusStop ... water - harbourPort - boatQuay - boatGangway ferry - ferryPort - ferryLanding - ferryGangway ... um nur ein paar aus der Liste zu nennen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buslinien Bahnhof
Dimitri Junker schrieb: Hallo, Ein Bahnsteig hat in den meisten Fällen schonmal mindestens zwei Haltepunkte Ich glaube wir sollten erstmal klären für wen der Haltepunkt gedacht ist, für den Zugführer oder für den Passagier? Gruß Dimitri wenn du das so fragst, würde ich den Haltepunkt immer den Fahrzeugführer zuschreiben. Was interessiert im Grunde den passagier wo das Fahrzeug wie anhalten muss, damit ich am Bahnsteig bequem in das Fahrzeug einsteigen kann. Wie gesagt. Ich empfehlte das IFOPT-Schema mal zu studieren. Die trennen da auch klar zwischen der Fahrzeugführer und der Passagierebene. Außerdem kann man damit nicht nur Bus und Bahn, sondern auch andere Verkehrsstrukturen abbilden. (einsteigen auf einem Schiff, oder den Weg vom Flughafen eingang bis hin ins Flugzeug). Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buslinien Bahnhof
Mario Salvini schrieb: Dimitri Junker schrieb: Hallo, im Grunde sind all diese Haltepunkte falsch, denn die Züge können überall zwischen den Ampeln halten. Willst Du Haltelinien einführen oder wie sieht Dein Verbesserungsvorschlag aus? Dimitri das war erst einmal nur ein Einwand, dass es in Bahnhöfen im Grunde keine Halte-Punkte gibt. Übrigens auch eine interessante Seite zu dem Thema: http://www.naptan.org.uk/ifopt/ Gruß Mario ich muss gstehen. meine Aussage war vermutlich sehr schwammig, aber Mirko hats eigentlich schön beschrieben. An einem Bahnhofsgleis muss kein seperates Halteschild stehen oder es stehen sogar mehere da. (je nach Spezifikation des Zuges hält der eine hier und der andere dort). Wenn kein seperates Halteschild (normalerweise schwarzes H auf weißem Grund) vorhanden ist, soll der Zug normalerweise bis zur Ampel vorfahren (Mirko korrigiere mich falls ich Mist rede ;) ) Also einfach einem Gleis immer und ausschließlich nur _einen_ Haltepunkt geben zu wollen hat nicht viel mit der Realität zu tun; und das hat nichts mit der Unschärfe zu tun, dass Züge hier nicht so puntgenau anhalten wie z.B. in Japan. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buslinien Bahnhof
Dimitri Junker schrieb: Hallo Mario, Also einfach einem Gleis immer und ausschließlich nur _einen_ Haltepunkt geben zu wollen hat nicht viel mit der Realität zu tun; Ich sehe die Möglichkeiten 0,1 mehrere Haltepunkte. Jede Position einer möglichen Tür ist Unsinn bleiben 0 oder 1. Irgendwie markieren das derZug dort halten kannmuß man bleibt 1 Haltepunkt KI oder NI. Oder was hast Du für einen Gegenvorschlag? Dimitri ich wollte nicht die Positionen der Eingangstüren mappen, keine Sorge ;) Mirko hat es glaube ich sehr gut erklärt, was ich meine :) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buslinien Bahnhof
Hi Dimitri, im Grunde sind all diese Haltepunkte falsch, denn die Züge können überall zwischen den Ampeln halten. Gruß Mario Dimitri Junker schrieb: Hallo, ich wollte mich mal wieder mit Buslinien beschäftigen, habe mit dem neuen Schema aber noch meine Probleme. Fangen wir mit der untersten Ebene an, den Haltestellen: im Wiki steht: Haltepunkte werden in die entsprechenden Buslinien-Relationen aufgenommen (Plattformen nicht!). Also nicht die Haltestellen-Relation sondern der Node richtig? Beim neuen Schema soll doch für beide Richtungen und jede Variante einer Buslinie eine eigene Relation angelegt werden, wäre es dann nicht sinnvoll auch anzugeben welche Platform für diese Richtung zusändig ist? Die site=stop_area Relation erhält ja u.a. Haltepunkt und Platform als member, bekommen die irgendeine Rolle? Buslinien In dieser Mailingliste wurde erwähnt, daß jede Richtung/Variante einer Buslinie einzeln als Relation getaggt werden soll. Dazu habe ich im Wiki nichts gefunden. Dazu die folgenden Fragen. Wie werden die Relations unterschieden? Die Richtung durch From/To und die Varianten durch... Gibt es eine übergeordnete Relation die diese zu einer Buslinie zusammenfaßt? Wenn man je Fahrtrichtung eine Relation hat muß dann noch forward/backward eingegeben werden oder wird dies automatisch erkannt? Und noch eine kurze Frage zum Aachener Hauptbahnhof: http://osm.org/go/0GAnMgEEv-?layers=0B00FTF Was muß hier gemacht werden, damit nicht an jedem Gleis Aachen Hbf steht? Ich vermute, die Haltepunkte zu einer Stop_area zusammenfassen und alle Namen löschen außer in der Relation? Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buslinien Bahnhof
Dimitri Junker schrieb: Hallo, im Grunde sind all diese Haltepunkte falsch, denn die Züge können überall zwischen den Ampeln halten. Willst Du Haltelinien einführen oder wie sieht Dein Verbesserungsvorschlag aus? Dimitri das war erst einmal nur ein Einwand, dass es in Bahnhöfen im Grunde keine Halte-Punkte gibt. Übrigens auch eine interessante Seite zu dem Thema: http://www.naptan.org.uk/ifopt/ Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutz- / Biosphärenreservat - G esetze = gemeinfrei ?
Jan Tappenbeck schrieb: Moin !!! Naturschutz- / Biosphärenreservat werden doch per Gesetz / Verordnung deklariert und definiert - damit müßten doch auch die Grenzen gemeinfrei sein oder ??? Dann hieße es nur noch irgendwie an die betreffende Datei zu gelangen ?!?!??! Gruß Jan :-) vielleicht einfach mal lieb beim BUND oder das Umweltministerium fragen? Die Karte von geocaching.de hat die Daten ja auch zur Verfügung gestellt bekommen (und wird angezeigt). -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
TeamAdiac schrieb: Hallo Zusammen, mir ist Heute beim Mappen eine Straße namens Im Gäßchen [1] über den Weg gelaufen. So steht es auf dem Schild. Steht die neue deutsche Rechtschreibung nun über dem Schild? Eigentlich sollte es doch Im Gässchen heißen. Ich lass’ es so stehen, weil’s auf dem Schild steht, aber was meint Ihr? MfG, Adiac [1] http://osm.org/go/0DWl9s9kz-- Ich würde es Im Gässchen eintragen und der Gemeindeverwaltung sagen, dass da ein Schreibfehler ist. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Tobias Wendorff schrieb: Johannes Hüsing schrieb: Nach heutiger Rechtschreibung wär Vossstraße korrekt, im Geschäftsverkehr verwenden wir Voßstraße, und so habe ich das auch gemappt. Ist denn der Nachname gemeint oder wirklich die plattdeutsche Variante für Fuchs? genau die Frage stellte ich mir auch gerade.. Wenn die STraße nach einem Herr/Frau Voß benannt ist, dann bleibsts natürlich bei Voßstraße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] waterway=lock
Peter Childs schrieb: 2009/8/28 wynnd...@lavabit.com: On 27/08/09 12:13, Jack Stringer wrote: lock=yes lock_name=Withrington Bottom Lock When you are tagging a way, you can't use name= because that will already contain the name of the canal. Hence lock_name=. Why would you want to repeat the name of a canal on its individual nodes? Isn’t that repeating the mistake of the TIGER node tags? Read it again. on a node lock=yes name=lock name or on a node waterway=lock_gate name=lock gate name and on the way between the lock gates waterway=canal name=canal name lock=yes lock_name=lock name The Canal way will need to be split at the lock gates, (or in some cases where a diversion starts (due to some rivers going over weirs) while there is a lock for boats. Peter. I really like this methode! let's do it that way :) -- Mario ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Guenther Meyer schrieb: Am Freitag 21 August 2009 schrieb Mario Salvini: Guenther Meyer schrieb: Am Donnerstag 20 August 2009 schrieb Florian Lohoff: On Thu, Aug 20, 2009 at 09:03:58AM +0200, Guenther Meyer wrote: On Thu, Aug 20, 2009 at 08:44:22AM +0200, Florian Lohoff wrote: Und ist Pfarrer, Propst, Bürgermeister, Stadtrat, Papst auch ein Titel? Duerfen die auch abgekuerzt werden? (Denn sie werden abgekuerzt) Wo ist die Grenze? trag's so ein, wie's auf dem schild steht, dann stellt sich die frage erst gar nicht ;-) Wenn eine anwendung da unbedingt mit rumpfuschen will (z.B. wegen zu wenig Platz zum rendern), dann ist das problemlos ueber ein dictionary, das zuordnungen wie bgm - buergermeister macht, moeglich - das hat aber die datenbank nicht zu kuemmern... Das Straßenschild ist die Authoritaet? Und wenn es ueberall anders steht als auf dem Straßenschild? Trotzdem so eintragen? Sehe ich nicht. was heisst ueberall? es gibt neben den schildern sonst nur noch die verzeichnisse der zustaendigen behoerden. und die koennen ebenso fehlerhaft sein. nochmal: nur das schild kann jeder sehen und vergleichen, man muss es dazu nicht mal lesen koennen! das ja. nur auch Schilder sind keine fehlerfreie Quelle. hab auch nie was anderes behauptet... Wenn ich daran denke wieviele Straßenschilder oder auch öffizielle Straßenlisten noch mit -strasse im Namen gelistet sind wird mir schwindelig. In Deutschland heißt es nunmal Straße und nicht Strasse, egal was auf dem Schild (falsch) steht ;-) vielleicht gab's im verwendeten zeichensatz einfach kein sz, soll ja vorkommen ;-) Wenn ich mich richtig erinnere lag das eher daran dass die Kommunen ganz modern und jeder der erste sein wollte der die Straßenschilder auf die neue Rechtschreibung umstellt. Eine Schreibweise ala Beispelstrasze kenne ich allerdings in Deutschland nur von Bauingenieuren und Architekten *g* -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Guenther Meyer schrieb: On Fri, Aug 21, 2009 at 08:25:36AM +0200, Mario Salvini wrote: vielleicht gab's im verwendeten zeichensatz einfach kein sz, soll ja vorkommen ;-) Wenn ich mich richtig erinnere lag das eher daran dass die Kommunen ganz modern und jeder der erste sein wollte der die Straßenschilder auf die neue Rechtschreibung umstellt. Eine Schreibweise ala Beispelstrasze kenne ich allerdings in Deutschland nur von Bauingenieuren und Architekten *g* mit sz meinte ich das scharfe s. wie ist denn die offizielle neue rechtschreibung, doch nicht wirklich strasze? urgs... neee nicht strasze ;-) Ich meinte damit eigentlich eher, dass es auf Bauplänen oder so üblich ist ß bei Großbuchstaben nicht mit SS sondern eben mit SZ geschrieben wird. Also z.B. BEISPIELSTRASZE. Das kenne ich aber wie gesagt nur aus Bauingenieur bzw. Architektenkreisen ;-) Straße wird nach alter und finaler neuen Rechtschreibung weiterhin Straße geschrieben (genau wie Gruß und Fuß). Strasse schien halt damals neudeutsch und das radikale Umschildern olitisch modern, aber falsch ist es dennoch ;) Nur jetzt haben die Gemeinden keine Lust wieder viel Geld auszugeben die Schilder erneut wieder alle auszutauschen, daher geschieht das pö-a-pö *g* (so entstehen dann auch so Beispiele, wo beide Schildervarianten in einer Straße zu finden sind) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Guenther Meyer schrieb: On Fri, Aug 21, 2009 at 08:29:34AM +0200, Matthias Versen wrote: Nunja, wir haben ja die Wahllisten und das ist ein Auszug aus der Liste der Stadt. ja, wir haben die listen vielleicht, aber nicht der nutzer der daten auf der strasse... Ich finde es halt sinnvoler Abkürzungen aufzulösen weil der Name dort eindeutig ist aber das ist halt Geschmackssache. eindeutig in welcher hinsicht? ich glaube nicht, dass es denselben strassennamen in verschiedenen schreibweisen im selben ort an mehreren verschiedenen strassen gibt... wichtiger ist mir da der wiedererkennungswert vor ort. gerade für den Wiedererkennungswert ist die ausgeschrieben Variante für den Schenden doch besser? Wenn ich z.B. dank OSM weiß, dass die Straße Josef-van-Görres-Straße heißt, dann kann ich vorOrt auch das Jos.-v.-Görres-Str. abstrahieren. Auch wenn ich einen Passanten nach dem Weg frage (kalr in Zeiten von GPS und Navi wohl eher retro, aber man pflegt ja gerne Kontakt mit den Eingeborenen ;-) ) Fragst du dann ja auch nicht wissen sie die josvangöresstrrr ist?, sondern du bist froh, wenn du den vollständigen Namen hast. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Andreas Fritsche schrieb: Hi, From: Mario Salvini salv...@t-online.de [..] In Deutschland hei?t es nunmal Stra?e und nicht Strasse, egal was auf dem Schild (falsch) steht ;-) Richtig ist, dass es in Deutschland 'Staße' heißt und nicht 'Strasse'. Aber das egal ist, was auf dem Schild steht, das ist IMHO falsch. Wenn eine Verwaltung entscheidet, dass die Straße 'Berliner Strasse' heißt, dann heißt die Straße 'Berliner Strasse' und nicht 'Berliner Straße'. Es ist ein Eigenname. Wird übrigens trotzdem 'Straße' gesprochen. - Für Namen gelten die lustigen Regeln nicht, liebe Germanisten, die Ihr Euch ausgedacht habt. Und meinetwegen kann auch gern der Wegbeschreibung stehen Die nächste Straße links ist die 'Berliner Strasse'. Das tut mir überhaupt nicht weh. Anders ist das mit dem Bot, der hin und wieder über die Karte flitzt und alle 'Strasse' durch 'Straße' ersetzt. /Andreas Berliner Strasse und Berliner Straße haben nunmal nicht die gleiche Aussprache. In Deutschland ist ss nunmal ein kurzer S-Laut ß nunmal ein langer. In anderen deutschsprachigen Ländern mag das aber durchaus anders sein, aber das ist hier ja nicht Teil der Diskussion. Der Bot ist nur für für die false positives doof. Also z.B. das die erwähnte Engelstrasse (also die Trasse vom Engel und nicht die Straße, die nach Engel benannt ist). -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Ropino schrieb: Hallo, im Zuge der Auswertung der Straßenlisten (http://osm.gt.owl.de/Strassenliste/) bin ich auf das Problem mit der zum Teil sehr unterschiedlichen Schreibweise von Straßennamen gestoßen. Die Regel, man schreibt es so wie es auf dem Schild steht, scheitert spätestens wenn eine Straße im gleichen Ort unterschiedliche Schreibweisen/Abkürzungen hat. Allgemeiner Konsens dürfte die Langform von Straße / -straße sein. Wie verfahren wir mit den Abkürzungen für: 1. Doktor - Dr. 2. Professor - Prof. 3. Sankt - St. Für Dr. und Prof. würde ich die Kurzform als üblich ansehen, bei Sankt tendiere ich eher zur Langform. Die amtlichen Straßenverzeichnisse helfen nicht wirklich weiter, da gibt es auch alle möglichen Varianten. - Bei Namensabkürzungen schlage ich vor, wenn möglich und bekannt die Langform zu nutzen. Beispiele: Wilh.-Busch-Str. - Wilhelm-Busch-Straße Dr.-C.-von-Linde-Straße - Dr.-Carl-von-Linde-Straße Schwieriger wird es bei Personen die es in verschieden Versionen gibt oder auch die Kurzform(en) üblich sind. Beispiel A: Annette-von-Droste-Hülshoff-Weg Von-Droste-Hülshoff-Weg Droste-Hülshoff-Weg Alle 3 Varianten habe ich schon gesehen, zum Teil als Straße statt Weg. Und davon natürlich auch wieder Abkürzungen wie: A.-von-Droste-Hülshoff-Weg A.-v.-Droste-Hülshoff-Weg Hier dürfte die oberen 3 Varianten jeweils richtig sein. Die unteren Varianten würde ich eher ausschreiben. Beispiel B: Carl-Maria-von-Weber-Straße C.-M.-von-Weber-Straße Carl.-M.-von-Weber-Straße Hier würde ich nur die 1. Variante als richtig ansehen, eventl. auch Variante 3? Beispiel C: John-F.-Kennedy-Straße Hier dürfte kaum jemand den kompletten Namen John-Fitzgerald-Kennedy-Straße erwarten. Ich würde mich freuen, wenn wir insbesondere bei Dr. / Prof. und Sankt einen allgemeinen Konsens finden können. Ausnahmen bestätigen dabei wie immer die Regel. ;-) Grüße Ropino Ich persönlich würde alle Abkürkungen ausschreiben. (Außer vielleicht bei Eigennamen bzw. Rufnamen siehe. John F. Kennedy. Bei den Amerikanern ist es ja üblich, dass der Mittelname nur mit dem Initial genannt wird. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Guenther Meyer schrieb: Am Donnerstag 20 August 2009 schrieb Florian Lohoff: On Thu, Aug 20, 2009 at 09:03:58AM +0200, Guenther Meyer wrote: On Thu, Aug 20, 2009 at 08:44:22AM +0200, Florian Lohoff wrote: Und ist Pfarrer, Propst, Bürgermeister, Stadtrat, Papst auch ein Titel? Duerfen die auch abgekuerzt werden? (Denn sie werden abgekuerzt) Wo ist die Grenze? trag's so ein, wie's auf dem schild steht, dann stellt sich die frage erst gar nicht ;-) Wenn eine anwendung da unbedingt mit rumpfuschen will (z.B. wegen zu wenig Platz zum rendern), dann ist das problemlos ueber ein dictionary, das zuordnungen wie bgm - buergermeister macht, moeglich - das hat aber die datenbank nicht zu kuemmern... Das Straßenschild ist die Authoritaet? Und wenn es ueberall anders steht als auf dem Straßenschild? Trotzdem so eintragen? Sehe ich nicht. was heisst ueberall? es gibt neben den schildern sonst nur noch die verzeichnisse der zustaendigen behoerden. und die koennen ebenso fehlerhaft sein. nochmal: nur das schild kann jeder sehen und vergleichen, man muss es dazu nicht mal lesen koennen! das ja. nur auch Schilder sind keine fehlerfreie Quelle. Wenn ich daran denke wieviele Straßenschilder oder auch öffizielle Straßenlisten noch mit -strasse im Namen gelistet sind wird mir schwindelig. In Deutschland heißt es nunmal Straße und nicht Strasse, egal was auf dem Schild (falsch) steht ;-) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] TagWatch Schluckauf?
letzter Stand is der 6.8. Gibts da Probleme oder bin ich einfach nur zu ungeduldig? :-) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] TagWatch Schluckauf?
letzter Stand is der 6.8. Gibts Probleme oder bin ich einfach zu ungeduldig? :-) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seezeichen werden komplett umgetaggt - ist das so immer richtig?
Jan Jesse schrieb: Hallo Leute, seit einigen Tagen werden alle Seezeichen, die bisher in den verschiedenen Projekten gesammlt wurden, systematisch umgetaggt. Dabei passiert zumindest bisher nicht unbedingt etwas schlimmes. Überflüssige Tags werden entfernt, und es wird ein einheitliches Tagging umgesetzt. Das einheitliche Tagging entspricht dabei den unterschiedlichen Proposals, die für Seezeichen derzeit existieren, indem beide Schemata (großteils redundant) abgebildet werden. Für den Übergang sicherlich eine sinnvolle Variante, stelle ich mir aber vor, daß diese Redundanz auf Dauer auch nicht das wahre ist. Es wäre schön, wenn sich der betreffende Nutzer mal melden, und kurz erklären könnte, was er vorhat? Vielleicht setzt das ja auch den von Mario initiierten Thread hinsichtlich des Proposals zum Seezeichen-Tagging nochmal in Gang? Nach meiner Meinung sind die derzeit existierenden Tagging-Schemata noch nicht ausgereift, und können sich gerade hinsichtlich kurzer, knapper und eingängiger Beschreibungen (sprechende tags) noch ein gutes Stück entwickeln. Nach dem Aufräumen, daß in der DB stattgefunden hat, würde ich es daher als positiv empfinden, wenn die nachträgliche Autokorrektur wieder abgeschaltet würde. So ein wenig Raum für Kreativität sollte doch sein, oder ;-) Beste Grüße aus Berlin JJ www.freietonne.de/seekart überflüssiges entfernt wird da eigentlich garnix so wie ich das im Überblick habe. Die werden halt alle mit den Tags des vorgeschlagenen Schemas in der Wiki gefüttert. Wenn du das Schema noch nicht für ausgereift hälst, dann diskutier doch einfach in der Wiki mit, dazu is dieses Instrument doch da ;) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 30km/h - Anlieger frei
Johann H. Addicks schrieb: Selbst wenn da noch das 250er drüber hinge, eine merkwürdige Kombination: http://www.addicks.net/gallery/bizar/P8080188 -jha- schaut eher so aus, als hätte das 30 Schild oben gehangen dadrunter ein durchfahrt verboten (roter Ring auf weißem Grund) und jemand hat sich den Spaß erlaubt da was umzumontieren. Sinn macht das so jedenfalls nicht *g* Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSMdocs letzter Stand?
Hallo Liste, wird OSMdocs noch aktualisiert? Scheint nämlich nicht so. Wäre echt schade drum. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] geteilte Fahrrad- Fußwege mit path
Marc Schütz schrieb: wer kennt das allgemeine Tagging für die vertikale Variante Ich empfehle, path nur zu verwenden, wenn _keine_ blauen schilder aufgestellt sind. Bei vertikaler teilung verwendet man: highway=cycleway foot=yes traffic_sign=z241 bei horizontaler: highway=cycleway foot=yes traffic_sign=z240 wenn dann bitte foot=designated und nicht nur foot=yes +1 Außerdem schadet es nicht, gleich noch bicycle=designated dazu zu setzen. highway=cycleway wird ja mal als bicycle=designated, mal als bicycle=yes interpretiert. Grüße, Marc +1 und segregated=yes zur unterscheidung, obs ein getrennter oder gmeinsamer Rad-/Fussweg ist halte ich immer noch für die einfachste und effektivste Variante. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxweight, hazmat, width und maxspeed map
Florian Lohoff schrieb: Hi, ich habe die maxspeed karte ein wenig aufgebohrt. Wahlweise koennen jetzt auch hazmat (Hazardous Material aka Gefahrgut), width, maxweight oder halt wie gehabt maxspeed visualisiert werden. Der permalink kennt im moment noch nicht den datentyp der zu visualisieren ist so das im moment dann immer maxspeed gezeigt wird - kommt demnaechst. http://maxspeed.osm.lab.rfc822.org Flo *Dank dir von einer Karte träumt, die Anzeigt wo hgv=no angezeigt wird* :-D Im Ernst, klasse Idee mit den Overlays :) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxweight, hazmat, width und maxspeed map
Florian Lohoff schrieb: On Mon, Aug 03, 2009 at 03:16:55PM +0200, Mario Salvini wrote: Subject: Re: [Talk-de] maxweight, hazmat, width und maxspeed map http://maxspeed.osm.lab.rfc822.org *Dank dir von einer Karte träumt, die Anzeigt wo hgv=no angezeigt wird* :-D Warum hgv? Mir fehlt da noch nen bischen das verstaendniss - So wie ich mal las ist hgv doch eine rechtliches konstrukt aus den usa was es hier gibt. Oder unterscheiden wir in D zwischen goods und hgv? Ich kenne entweder die tonnagebeschraenkung oder aber das umgangssprachliche fuer LKW verboten. Flo im Grunde fallen da goods und hgv zusammen. Denn beim schwarzen LKW-Symbol auf weißem Grund in rotem Ring sind afaik beide Typen mit gemeint. Was die Gewichtung angeht is aber ja ein Unterschied im zulässigen maxweight. 2.8 goods 3,5t und hgv 3.5t -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxweight, hazmat, width und maxspeed map
Florian Lohoff schrieb: On Mon, Aug 03, 2009 at 03:46:50PM +0200, Mario Salvini wrote: im Grunde fallen da goods und hgv zusammen. Denn beim schwarzen LKW-Symbol auf weißem Grund in rotem Ring sind afaik beide Typen mit gemeint. Was die Gewichtung angeht is aber ja ein Unterschied im zulässigen maxweight. 2.8 goods 3,5t und hgv 3.5t Von meinem LKW Fuehrerschein meine ich mich zu erinnern das die 2.8t nur in der Deutschen StVO auftaucht weil das die ehemalige Deutsche Belastungsgrenze fuer Buergersteige war - In den restlichen EU Laendern aber tendentiell immer 3.5t - Daher auch die neuen EU Fuehrerscheine mit 3.5t - Dann kenne ich die grenze 7.5t und entsprechend 40t. Gibt es denn in der StVO oder StVzO die 2.8-3.5t klasse? Flo wenn ich mich richtig erinnere dürfen Leute mit neuem EU-Führerschein nur PKWs bis 2.8t bewegen. Alles was schwerer sein darf ist kein PKW. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] geteilte Fahrrad- Fußwege mit path
Martin Koppenhoefer schrieb: Am 2. August 2009 14:36 schrieb Jörk jo...@jhamburger.de: Martin Koppenhoefer schrieb: wer kennt das allgemeine Tagging für die vertikale Variante moin, Du hast das http://wiki.openstreetmap.org/wiki/DE:Road_Signs Danke, hatte ich gerade nicht gefunden. sicher gesehen? Obwohl bei der waagerechten Variante haben meiner Erinnerung nach die Fußgänger Vorrecht. nun gut, das Vorrecht ergibt sich ja auch der rechtlichen Lage, sofern man diese unmissverständlich abbildet, ist das Vorrecht da schon eingeschlossen und braucht nicht explizit getaggt werden. Wir taggen ja auch nicht rechts-vor-links an jeder Straßenkreuzung. die Abgrenzung zur horizontalen Variante ist demnach ein segregated=yes. Gruß Martin ob segregated=yes oder nciht hat auch Auswikungen aufs maxspeed der Radfahrer, wenn ich mich da richtig erinnere. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] geteilte Fahrrad- Fußwege mit path
Karl Eichwalder schrieb: Jörk jo...@jhamburger.de writes: Martin Koppenhoefer schrieb: wer kennt das allgemeine Tagging für die vertikale Variante Ich empfehle, path nur zu verwenden, wenn _keine_ blauen schilder aufgestellt sind. Bei vertikaler teilung verwendet man: highway=cycleway foot=yes traffic_sign=z241 bei horizontaler: highway=cycleway foot=yes traffic_sign=z240 wenn dann bitte foot=designated und nicht nur foot=yes Du hast das http://wiki.openstreetmap.org/wiki/DE:Road_Signs sicher gesehen? Obwohl bei der waagerechten Variante haben meiner Erinnerung nach die Fußgänger Vorrecht. Ja, so ungefähr. Wenn was passiert, ist der radfahrer jedenfalls als stärker verkehrsteilnehmer (oder wie immer das heißen mag) in erster linie schuldig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Martin Koppenhoefer schrieb: Am 26. Juli 2009 21:09 schrieb Mario Salvini salv...@t-online.de: scheinbar bin ich zu native-speaker afine.. für mich heißt amanity=drinking_water -- Süsswasser. nicht mehr nicht weniger ;) vielleicht beruhigt es Dich zu wissen, dass z.B. das Trinkwassersicherheitskonzept der WHO „Managing drinking-water from catchment to consumer“ heißt. Süßwasser nennt LEO übrigens freshwater. Diese Diskussion ist in meinen Augen etwas müßig, da wie schon geschrieben m.E. die von uns definierte Bedeutung entscheidend ist, nach der wir taggen, und nicht irgendwelche Sprachanalysen nach der Art: wer googelt am besten. Gruß Martin wieder was gelernt. Danke dir Martin :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [ÖPNV] Haltestellenschema - Praxi serfahrung
Fips Schneider schrieb: Thomas Reincke schrieb: Fips Schneider schrieb: Dazu sind mir folgende Probleme aufgefallen: - die Stop-Positions bekommen nach dem Schema keinen Namen. Das ist aber sehr unpraktisch, wenn man in der Relation die richtigen Punkte noch erkennen will (in der Übersicht aller Teile der Relation). Ich habe sie jetzt einfach mal benannt nach dem Schema Südbahnhof (Tram/Bus/U-Bahn) Gleis 1 Die Namen kommen an die Platform. Als Name würde ich Gleis 2, Bussteig 7 etc. dranschreiben. Das Problem ist dann aber, dass Du namenlose Nodes hast, die in eine Relation eingefügt sind. Im Relation-Editor erscheinen dann 20+ Nodes die nur die Koordinaten haben. Das halte ich für vollkommen unpraktikabel. Was spricht denn dagegen, den stop_positions Arbeitsnamen zu geben. Dann sieht man in der Relation bspw. U1: Südbahnhof - Gleis 2, Schweizer Platz - Gleis 2, ... ? Gibt es eigentlich ein einheitliches Namensschema für Bahnsteige die zwei Gleise haben (was ja eher der Normalfall ist)? Ich hatte mit Gleis 22 - 23 angefangen, jetzt hat aber jemand alle in Gleis 22 und 23 umbenannt was ich für unglücklich halte wegen dem überflüssigen Wort (aber vielleicht ist das auch nur eine persönliche Abneigung). Gibt es bei der DB eine offizielle Schreibweise? Gleis 22/23? Gleis 22/Gleis 23 (auch wieder so lang)? ich bin immer noch davon überzeugt, dass Gleis X auch ans Gleis selber kommt und nicht an die Plattform. Dann muss man auch nicht eine große Plattform pseudo-teilen nur weil da zwei Gleise dran lang laufen. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Josias Polchau schrieb: Martin Koppenhoefer schrieb: z.B. weil amenity=drinking_water schon 4480 mal in Europa verwendet wird und div. Anwendungen es unterstützen? wie von den Vorposteren dargelegt, bringt das einem wenig, wenn man nicht trinkbares Wasser taggen will. amenity wenn wir weiterhin so viel amenity benutzen können wir es gleich in POI umbenennen. eine andere bedeutung hat es in der OSM welt nämlich nicht mehr, und dann können wir es eigentlich gleich weglassen. weil es eine redundante Information ist. POI ist jeder Punkt, da er, wenn er nicht interessant wäre, nicht eingetragen worden wäre. im englischen ist soweit ich weiß drinking water alles Süßwasser. Nicht nur dass, was nach deutschen Normen aus der Wasserleitung tropft. Das Schrebergarten oder Brunnenwasser wäre also auch drinking water Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäche, wie zu taggen
Lothar Emmerich schrieb: * Muss jeder Bach eingetragen werden? Es gibt Rinnsale, die nur bei starkem Regen Wasser führen. Daraus ergibt sich .. ich würde sagen ja. Man nehme z.B. die Flussbetten in Afrika. Die führen meist nur zu bestimmten Jahreszeiten Wasser. In der anderen Hälfte sind sie Knochentrocken. Warum sollte man die aber nicht einzeichnen :) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserzapfstelle im Schrebergarten
Martin Koppenhoefer schrieb: Am 26. Juli 2009 20:38 schrieb Mario Salvini salv...@t-online.de: im englischen ist soweit ich weiß drinking water alles Süßwasser. Nicht nur dass, was nach deutschen Normen aus der Wasserleitung tropft. Das Schrebergarten oder Brunnenwasser wäre also auch drinking water jaja, ursprünglich hieß der Vorschlag daher ja auch potable water. Dann kamen aber einige daher und haben gesagt, für non-native speakers wäre drinking_water besser verständlich. Entscheidend ist ja nicht die englische Bedeutung sondern die Bedeutung in OSM. Gruß Martin scheinbar bin ich zu native-speaker afine.. für mich heißt amanity=drinking_water -- Süsswasser. nicht mehr nicht weniger ;) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kennzeichnung der Flusskilometer
Seehundeführer schrieb: Markus Koelle mkoelle at gmx.de writes: Hallo, wie werden die Flusskilometer von Flüssen und Strömen gekennzeichnet? Gruß Markus Hi Markus, analog zu higway:milestone hab ich in irgendeinem Wiki mal waterway:milestone als Vorschlag gelesen. Als zweiten Tag dann noch milestone:[km] mit dem Zahlenwert des Flusskilometers oder Hektometersteines. ciao Mirko Hi Mirko, meintest du nicht waterway=milestone und milestone=[km] ? -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Schweiz und Südtiro l
Sven Geggus schrieb: Werner König wkg.koe...@googlemail.com wrote: Dass das die OSM-Lizenz verbietet, da OSM-Daten auch kommerziell genutzt werden dürfen und die eingemischten eben nicht, ist klar. Aber welche Daten werden benutzt, die nur für nicht kommerzielle Nutzung frei sind. Von CIAT aufbereitete SRTM Höhendaten. Sven sind da eigentlich auch brauchbare Wassertiefenangaben drin? -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Frederik Ramm schrieb: Hallo, Mario Salvini wrote: es liegt wohl einfach daran, dass ich den gewählten Bereiff stop_area völlig uninuitiv genutzt sehe und deshalb auch Probleme mit dem Schema habe. Der Begriff ist allerdings einem internationalen Standard entnommen (IFOPT bzw. Transmodel definieren Stop Area = A group of Stop Points close to each other - also genauso wie Sebastian in seinem Konzept). Ein Stop Point wiederum ist a point in a planned journey where passengers can board or alight from vehicles. Man sieht, dass diese Standards eher aus Passagiersicht denn aus Betriebssicht geschrieben sind - wo genau jetzt die Vorderkante vom Fahrzeug haelt, ist egal, Hauptsache, der Passagier kann einsteigen ;-) Ich bin mitnichten ein blinder Verfechter von internationalen Standards, aber wenn es die halt schon mal gibt und wenn sie nicht ganz bloedsinnig sind, dann ist es schon nicht schlecht, deren Begriffe weiterzuverwenden, das sorgt dann fuer weniger Missverstaendnisse, wenn man es mit Leuten zu tun hat, die sich in der Branche schon auskennen. Hier ist ein Dokument zum IFOPT-Standard, das auch die Transmodel-Begriffe enthaelt: http://www.naptan.org.uk/ifopt/ifoptV1.0-36/CENTC278WG3SG6_IFOPT_20081110_36.pdf Bye Frederik nach diesem Papre finde ich ist dass was wir scheinbar zusammenfassen wollen eher eine ADMINISTRATIVE AREA (IFOPT) A grouping of STOP PLACE, PLACE or other managed data for management by a DATA ADMINISTRATOR. Each administrative area will have a common IDENTIFIER NAMESPACE for allocating identifiers. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Frederik Ramm schrieb: Hallo, Mario Salvini wrote: es liegt wohl einfach daran, dass ich den gewählten Bereiff stop_area völlig uninuitiv genutzt sehe und deshalb auch Probleme mit dem Schema habe. Der Begriff ist allerdings einem internationalen Standard entnommen (IFOPT bzw. Transmodel definieren Stop Area = A group of Stop Points close to each other - also genauso wie Sebastian in seinem Konzept). Ein Stop Point wiederum ist a point in a planned journey where passengers can board or alight from vehicles. Man sieht, dass diese Standards eher aus Passagiersicht denn aus Betriebssicht geschrieben sind - wo genau jetzt die Vorderkante vom Fahrzeug haelt, ist egal, Hauptsache, der Passagier kann einsteigen ;-) Ich bin mitnichten ein blinder Verfechter von internationalen Standards, aber wenn es die halt schon mal gibt und wenn sie nicht ganz bloedsinnig sind, dann ist es schon nicht schlecht, deren Begriffe weiterzuverwenden, das sorgt dann fuer weniger Missverstaendnisse, wenn man es mit Leuten zu tun hat, die sich in der Branche schon auskennen. Hier ist ein Dokument zum IFOPT-Standard, das auch die Transmodel-Begriffe enthaelt: http://www.naptan.org.uk/ifopt/ifoptV1.0-36/CENTC278WG3SG6_IFOPT_20081110_36.pdf Bye Frederik STOP AREA Transmodel A group of STOP POINTS close to each other. Auch das interpretiere ich anders als du. Eine Stop-Area wäre dann z.B. der Bereich an einem Ende des Gleises wo verschiedene Stoppunkte versammelt sind. Aber nicht quasi der gesamte Bahnhof sei eine stop_area. Wenn irgendwann mal einer einen Flughafen nach diesem Schema erfassen möchte (was im Grunde kein Problem wäre) dann wäre plötzlich ein ganzer Flughafen eine stop_area? Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Frederik Ramm schrieb: Hallo Mario, Mario Salvini wrote: STOP AREA Transmodel A group of STOP POINTS close to each other. Auch das interpretiere ich anders als du. Eine Stop-Area wäre dann z.B. der Bereich an einem Ende des Gleises wo verschiedene Stoppunkte versammelt sind. Ein Stop Point ist aber nicht ein Punkt, an dem der Zug haelt, sondern, wie ich schrieb: a point in a planned journey where passengers can board or alight from vehicles. Du kannst gern Deine eigene Deutung dieser Begriffe haben - IFOPT ist zuweilen ziemlich witzig, so werden Bahnsteige usw. dort Quay genannt, obwohl der Begriff in der Umgangssprache nur fuer Schiffe benutzt wird. Aber wenn Du mit jemandem aus der Branche sprichst, dann gibt es da keinen Interpretationsspielraum - da ist ein Stop Point eben das, was ich oben schrieb, und hat mit Passagieren zu tun, die an einem Ort ein- oder aussteigen, und nicht mit Fahrzeugen, die an einem Ort halten. Nun kann man sagen: Lass uns bei OSM lieber das machen, was jeder versteht, als das, was in der Branche ueblich ist - machen wir sonst ja auch so. Aber ich finde, die Begriffe sind hier mittlerweile so komplex, dass man auch fuer das, was jeder versteht eine Wiki-Seite konsultieren muss. Ich finde jetzt Deine Argumentation, ein Stop Point sei praktisch da, wo die Nase des Zugs anhaelt, auch nicht klarer oder weniger klar als die von IFOPT. vielleicht meinen wir in OSM mit unserem Node ja eher einen VEHICLE STOPPING PLACE (IFOPT) A place on the vehicle trackway where vehicles stop in order for passengers to board or alight from a vehicle. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Frederik Ramm schrieb: Hallo Mario, Mario Salvini wrote: STOP AREA Transmodel A group of STOP POINTS close to each other. Auch das interpretiere ich anders als du. Eine Stop-Area wäre dann z.B. der Bereich an einem Ende des Gleises wo verschiedene Stoppunkte versammelt sind. Ein Stop Point ist aber nicht ein Punkt, an dem der Zug haelt, sondern, wie ich schrieb: a point in a planned journey where passengers can board or alight from vehicles. Du kannst gern Deine eigene Deutung dieser Begriffe haben - IFOPT ist zuweilen ziemlich witzig, so werden Bahnsteige usw. dort Quay genannt, obwohl der Begriff in der Umgangssprache nur fuer Schiffe benutzt wird. irgendeinen Namen musste man dem Kind halt geben. Und da die Seefahrt die älteste Transportbranche ist, wo solche Strukturen nötig gewesen wären, finde ich die Namens schon verständlich/nachvollziehbar Aber wenn Du mit jemandem aus der Branche sprichst, dann gibt es da keinen Interpretationsspielraum - da ist ein Stop Point eben das, was ich oben schrieb, und hat mit Passagieren zu tun, die an einem Ort ein- oder aussteigen, und nicht mit Fahrzeugen, die an einem Ort halten. Nun kann man sagen: Lass uns bei OSM lieber das machen, was jeder versteht, als das, was in der Branche ueblich ist - machen wir sonst ja auch so. Aber ich finde, die Begriffe sind hier mittlerweile so komplex, dass man auch fuer das, was jeder versteht eine Wiki-Seite konsultieren muss. Ich finde jetzt Deine Argumentation, ein Stop Point sei praktisch da, wo die Nase des Zugs anhaelt, auch nicht klarer oder weniger klar als die von IFOPT. hab das PDf mal weiter studiert. STOP PLACE (IFOPT) A place comprising one or more locations where vehicles may stop and where passengers may board or leave vehicles or prepare their trip. A STOP PLACE will usually have one or more well known names. Das trifft glaube ich ganz gut, was wir bis jetzt mit stop_area erfassen möchten. Wenn ich das Stop Place Model richtig verstehe haben die da: STOP PLACE : wäre quasi der Bahnhof, oder der Hafen, Flughafen, Bushaltestelle ( die logische Haltestelle mit allen Haltepunkten) dann wird unterschieden zwischen Vehicle Area und Passenger Area die Vehicle Area erfasst dann Dinge wie VEHICLE STOPPING PLACE und VEHICLE STOPPING POSITION. Es gibt also sehr wohl Information wo das Verkehrsmittel steht bzw. stehen bleibt. Durch die stopping_position wird hier sogar zwischen einzelen nichtverbundenen Waggons unterschieden. auf der passenger area wird dann nochmal zwischen QUAYs und ACCESS SPACEs unterschieden. Also quasi der Wartezone (QUAY) was wir momentan als plattform markieren und dem Zugangsereich zu den QUAY/plattform, die wir momentan irgendwie garnicht erfassen (wollen?). Die Positionen wo die Passagiere vom QUAY/plattform in die Transportmittel kommen wird mit BORDING POSITION erfasst. Das wären auf Bahnhöfen grob da, wo die buchstabierten Bereiche markeirt sind, man könnte es aber auch punktgenau über die VEHICLE STOPPING POSITION erreichnen. Bei Bushaltestellen wäre das da, wo die vordere Tür des Busses ist. da das aber quasi deckungsgleich mit der stopping_position ist braucht man dass denke ich eher nciht extra zu machen (zur Vereinfachnung) Wenn man dass ins OSM überträgt bräuchte man für eine Station,Haltestelle nur eine STOP PLACE relation wo man alles reinpacken könnte und dann mit den oben genannten Begriffen eine Role gibt. Das wäre ein einfacheres und doch gleichzeitig flexibleres Schema. Außerdem wäre es noch voll ausbaufähig zum IFOPT-Schema. Wem das gerade zuviele unbekannte Begriffe waren schaut auch mal im PDF das Beispielbild auf S.42 an. Wenn irgendwann mal einer einen Flughafen nach diesem Schema erfassen möchte (was im Grunde kein Problem wäre) dann wäre plötzlich ein ganzer Flughafen eine stop_area? Das IFOPT-Dokument, das ich Dir genannt habe, behandelt Flughaefen ab Seite 57. Ich moechte ungern so weit ins Detail gehen, aber IFOPT fuehrt selber einen neuen Begriff STOP PLACE, der grob gesagt einen Gesamthalt oder auch einen ganzen Flughafen beschreibt und bei uns wohl am ehesten der vorgeschlagenen stop_area_group entspricht. Selbst da, wo IFOPT sich total ins Detail vertieft, wie z.B. im Bild auf S. 43, siehst Du immer noch die Passagierbezogenheit - dort sind einzelne boarding positions modelliert, also die Stellen auf dem Bahnsteig, wo man stehen muss, um in einen bestimmten Wagen zu kommen. Wo genau der Zugfuehrer den Zug stoppt, interessiert aber selbst auf diesem Level immer noch nicht - es geht immer nur darum, was der Passagier machen muss bzw. kann. VehicleStoppingPosition und BoardingPosition korrelieren beim Zug nunmal 1zu1. Beim Bahnverkehr kann man die BoardingPositions sogar automatishc generieren in Anhängigkeit der StoppingPosition. Bei See- oder Luftfahrt klappt dass hal nicht ohne eine explizite BoardingPosition. Gruß Mario
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Frederik Ramm schrieb: Hallo, Mario Salvini wrote: hab das PDf mal weiter studiert. STOP PLACE (IFOPT) A place comprising one or more locations where vehicles may stop and where passengers may board or leave vehicles or prepare their trip. A STOP PLACE will usually have one or more well known names. Das trifft glaube ich ganz gut, was wir bis jetzt mit stop_area erfassen möchten. Nein, die STOP AREA ist im IFOPT-Dokument ja nochmal separat definiert als A group of Stop Points close to each other. Ich will jetzt auch nicht fuer mich beanspruchen, das alles 100% verstanden zu haben, aber IMHO ist STOP PLACE sowas wie der ganze Flughafen, und STOP AREA ist sowas wie Frankfurt Flughafen Fernbahnhof. Ich wuerde sagen, dass dem STOP PLACE unsere stop_area_group entspricht. auf der passenger area wird dann nochmal zwischen QUAYs und ACCESS SPACEs unterschieden. Also quasi der Wartezone (QUAY) was wir momentan als plattform markieren und dem Zugangsereich zu den QUAY/plattform, die wir momentan irgendwie garnicht erfassen (wollen?). Wie Jochen schon gesagt hat - uns ging es ja darum, mal etwas praktisch Anwendbares zu etablieren. IFOPT hat viele gute Sachen drin, aber ich denke, da kommen wir erst in einigen Jahren hin, dass wir solche Details in OSM erfassen - wenn wir jetzt mit einer OSM-Version von IFOPT an den Start gingen, wuerden uns die nicht-pufferkuessenden Mapper doch schreiend davonlaufen. Wenn man dass ins OSM überträgt bräuchte man für eine Station, Haltestelle nur eine STOP PLACE relation wo man alles reinpacken könnte und dann mit den oben genannten Begriffen eine Role gibt. Man verloere dabei die Moeglichkeit, die wir bei uns mit dem zweistufigen stop_area/stop_area_group haben, naemlich dass man Dinge innerhalb eines Gesamthalts gruppieren kann (das Europaplatz-Beispiel aus Sebastians Wikiseite). Bye Frederik STOP PLACE kann beides sein, denn es ist rekursiv anwendbar (is neighbor of oder is subpoart of). Man kann also beliebig verschachteln (bei uns nur eine Ebene). Persönlich finde ich die offene Variante besser, da flexibler. Grundsätzlich sagt das IFOPT-Schema vereinfacht: Es gibt einen *STOP PLACE*. Dieser hat *ACCESS SPACE*s (z.B: Bahnhofshalle, Shops, etc) *QUAY*s (z.B. airlineGate, railPlattform, busStop, taxiStand...) , der *BOARDING POSITION* (aus Passagiersicht wo man sich befinden muss, um das Vehicle betreten zu können) und den *VEHICLE STOPPING PLACE* (bzw. POSITION) aus Transportmittel Sicht (wo das Vehicle zum stehen kommt). Diese 4 bzw. 5 Dinge werden wir auf lange Sicht in jedem Fall brauchen. Bei Bahnhöfen haben wir ohne ja jetzt schon Probleme. (Bei aller Kritik möchte ich mal deutlich anmerken, dass ich eure Arbeit ins keinster Weise kleinreden möchte. Im Gegenteil sowas zu entwickeln is immer ne sehr intensive Arbeit.) Produktive Grüße :) Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Jochen Topf schrieb: On Fri, Jul 17, 2009 at 03:02:48PM +0200, Mario Salvini wrote: STOP PLACE kann beides sein, denn es ist rekursiv anwendbar (is neighbor of oder is subpoart of). Man kann also beliebig verschachteln (bei uns nur eine Ebene). Persönlich finde ich die offene Variante besser, da flexibler. Rekursiv ist sehr problematisch, weil schwierig zu verarbeiten. Da haben wir uns beim Workshop explizit dagegen entschieden. Jochen im Grunde nur Schade aber auch kein echter Nacheteil, denn in den meisten Fällen wird es wahrscheinlich nicht mehr als eine Übergruppe geben. Bei sehr großen Anlagen (z.B. ein int. Flughafen) wären mehre logische Ebenen nett gewesen. stop_place_group = Relation mit namen internationaler Flughafen mitglieder: access_space.1 = Halle, Wege, Rolltreppen, Aufzüge, alle stop_place Relations stop_place.1 = Relation für Terminal 1 mitglieder: access_space.X = Flure, Rolltreppen, Aufzüge, Geschäfte des Terminals quay.X = Gate X bording_position.1 = Einlass erste Klasse von Gate X bording_position.2 =Einlass Economy von Gate X vehicle_stop_place = wo das Flugzeug geparkt hat an Gate X stop:area.2 = Terminal tiefergehende Details wie die einzelnen Abfertigungsstufen (Checkpoints: Check-in, Zoll, etc.) könnte man dan später steitig hinzufügen. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Dimitri Junker schrieb: Hallo, Ansatz für eine weitere Grüppchenbildung sehe ich nicht. Da reicht m. E. eine stop_area. Also wenn ich es richtig verstanden habe, dann ist eine stop_area die Verbindung eines Haltepunktes und einer Platform. Am Hansemannplatz gäbe es also 5 stop_areas, aber da alle Den Namen Hansemannplatz tragen bilden sie eine stop_area_group. so isses ja momentan glaube ich auch drin. Der eigentliche Clou für die Group sieht man aber an so stellen, wie dem Hauptbahnhof oder Haltestelle Schanz. Denn Bus und Bahn und Taxistand werden so mieinander verknüpfbar. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Jochen Topf schrieb: On Thu, Jul 16, 2009 at 10:50:40AM +0200, Dimitri Junker wrote: Ansatz für eine weitere Grüppchenbildung sehe ich nicht. Da reicht m. E. eine stop_area. Also wenn ich es richtig verstanden habe, dann ist eine stop_area die Verbindung eines Haltepunktes und einer Platform. Am Hansemannplatz gäbe es also 5 stop_areas, aber da alle Den Namen Hansemannplatz tragen bilden sie eine stop_area_group. Nein. Eine stop_area kann auch mehrere Haltepunkte und Plattformen umfassen. Typischerweise ist alles, was den gleichen Haltestellennamen trägt, eine einzige stop_area. Eine stop_area_group braucht man dann, wenn mehrere Haltestellen sehr nah zusammenliegen. Z.B. gibt es in Karlsruhe die Haltestelle Karlsruhe Hauptbahnhof der DB und Bahnhofsvorplatz, wo die Strabas und Busse abfahren. Das sind nach dem Namen verschiedene Haltestellen, aber sie werden als Gruppe erfaßt, weil man dort umsteigen kann. Wenn man wissen will, welche Plattform zum welcher stop_position gehört, dann kann man das nur über die Linienrelationen machen, in der beide drin sein sollten. Der Grund warum wir auf dem Workshop dafür keine Extra-Relation haben wollten, ist einfach, dass das noch eine Ebene mehr an Relationen eingezogen hätte. Jochen Hi Jochen, leider liegt genau da der Schwachpunkt des Systems. Das klappt bei Zügen z.B. garnicht, weil die z.B: in einem Bahnhof mehere hundert Meter haben wo sie halten können. Ein nachvollziehbares Schema wäre da. stop_position - markiert die Stop-Position wo Bus/Bahn mit ihrer Spitze hält. stop_area - der Bereich wo sie gehalten werden kann. In Bahnhöfen z.B. der Bereich zwischen den Ein-/Ausfahr-Ampeln. stop_area_group wäre dann z.B. alle Gleise eines Bahnhofs (und Taxistand Bushaltestellen am Vorplatz von mir aus auch) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Dimitri Junker schrieb: Hallo, stop_position - markiert die Stop-Position wo Bus/Bahn mit ihrer Spitze hält. Bei Zügen würde das in Japan funktionieren, hier halten die doch wo sie gerade Lust haben, weshalb das mit den Wagenstandsanzeigern so schlecht klappt. Bei Bussen klappt es garnicht, da auch mehrere hintereinander stahen können. Dimitri is natürlich alles eine frage, wie gewissenhaft ein Lokführer oder Busfahrer ist. Aber rein theoretisch haben sowohl Bus als auch Bahn feste Stop-Positionen (wie schon erwähnt sind es in Bahnhöfen meist mehrer in jede Richtung). Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMTransport - ÖPNV-Karte
Jochen Topf schrieb: On Thu, Jul 16, 2009 at 10:50:40AM +0200, Dimitri Junker wrote: Ansatz für eine weitere Grüppchenbildung sehe ich nicht. Da reicht m. E. eine stop_area. Also wenn ich es richtig verstanden habe, dann ist eine stop_area die Verbindung eines Haltepunktes und einer Platform. Am Hansemannplatz gäbe es also 5 stop_areas, aber da alle Den Namen Hansemannplatz tragen bilden sie eine stop_area_group. Nein. Eine stop_area kann auch mehrere Haltepunkte und Plattformen umfassen. Typischerweise ist alles, was den gleichen Haltestellennamen trägt, eine einzige stop_area. Eine stop_area_group braucht man dann, wenn mehrere Haltestellen sehr nah zusammenliegen. Z.B. gibt es in Karlsruhe die Haltestelle Karlsruhe Hauptbahnhof der DB und Bahnhofsvorplatz, wo die Strabas und Busse abfahren. Das sind nach dem Namen verschiedene Haltestellen, aber sie werden als Gruppe erfaßt, weil man dort umsteigen kann. Wenn man wissen will, welche Plattform zum welcher stop_position gehört, dann kann man das nur über die Linienrelationen machen, in der beide drin sein sollten. Der Grund warum wir auf dem Workshop dafür keine Extra-Relation haben wollten, ist einfach, dass das noch eine Ebene mehr an Relationen eingezogen hätte. Jochen es liegt wohl einfach daran, dass ich den gewählten Bereiff stop_area völlig uninuitiv genutzt sehe und deshalb auch Probleme mit dem Schema habe. Eine Stop Area ist in meinen Augen das Gebiet wo das Transportmittel hält/stoppt. Was ihr damit aber ausdrückt ist eher sowas wie group_of_halts oder was in der Art, aber stop_area triffts nicht. http://tools.geofabrik.de/osmi/?view=pubtrans_stopslon=6.09492lat=50.76921zoom=17baselayer=Public%20Transport Schließlich hät der Bus nicht an einem Beliebigen Ort in diesem Beispiel-Gebiet ;) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FreieTonne kann jetzt JOSM - Seezeichen anzeigen und direkt editieren
Olaf Hannemann schrieb: Hallo Jan, schafft ihr es den auch irgendwann einmal eure eigenen Daten zu lesen? http://www.freietonne.de/osm/?zoom=15lat=54.16763lon=12.10987layers=0B0T vs. http://openseamap.org/map/map_full.html?zoom=15lat=54.17lon=12.09618layers=B0T SCNR Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de wie war das mit dem Glashaus.? *g* :-P http://openseamap.org/map/map_full.html?zoom=14lat=54.00297lon=11.3246layers=B0T vs. http://www.freietonne.de/osm/index.php?lat=54.00297lon=11.3246zoom=13layers=B00T Das ist jetzt keineswegs böse oder gehässig gemeint. Es zeigt halt nur schön deutlich, dass beide Sub-Projekte noch in der Entwicklung sind und keiner instant auf alle Neuerungen(egal ob Daten oder Struktur) reagieren kann. Der forsche Ton is also irgendwie unnötig, obwohl ich verstehen kann, dass es nervenzehrend ist, wenn beide Seiten scheinbar ständig aneinander vorbeireden. Konstruktive Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
Tobias Wendorff schrieb: Hallo Community, OpenStreetMap verwendet als Datenmodell das sogenannte Spaghetti-Modell. Punkte, Linien und Flächen werden eingegeben, haben aber nicht immer eine topologische Verbindung untereinander. Daher gibt es z.B. häufiger die Diskussion, ob man Flächen bis an die Straßenachse (den Way) zeichnen soll oder nicht. Ich bin eigentlich ein Befürworter der Variante, dass man die Fläche an die Achse zeichnet, damit eine Verbindung hergestellt werden kann [1] Nun möchte ich aber eintragen, dass ein Zaun zwischen Straße und Fläche liegt. Dazu zeichne ich also einen Way mit *barrier = fence*, der genau auf den Nodes der Straße Fläche liegt - diese teilen sich ja dann alle Nodes. Aber wie weise ich nun darauf hin, dass der Zaun sich auf die Fläche bezieht? Das geht momentan doch nur durch eine Site-Relation [2], oder? Das alte fence = yes wäre irreführend, da es nicht angegeben würde, wo der Zaun anfängt und endet. Grüße Tobias Referenzen: [1] http://wiki.openstreetmap.org/wiki/User:TobWen/Flächen [2] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site das löst du am einfachsten, indem du die Fläche nciht bis zum Way ziehst und an den Nodes der Fläche entlang den fence-Way zeichnest. Wenn du schon durch den Zaun die genaue Info hast, wo die Fläche endet sollte es auch vor dem Straßen-Way enden. Weil schließlich läuft der Zaun nicht auf der Straßenmittellinie. Aber da is bestimmt noch nciht das letzte Wort gesprochen, um das optimal zu lösen :) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] eingezäunte Bereiche
Tobias Wendorff schrieb: Mario Salvini schrieb: das löst du am einfachsten, indem du die Fläche nciht bis zum Way ziehst und an den Nodes der Fläche entlang den fence-Way zeichnest. Wenn du schon durch den Zaun die genaue Info hast, wo die Fläche endet sollte es auch vor dem Straßen-Way enden. Weil schließlich läuft der Zaun nicht auf der Straßenmittellinie. Ein normales GPS-Gerät liefert mir leider keine genaue Information, wo der Zaun liegt. Die Breite einer Straße kann ich allerdings genau bestimmen und auch die Lage des Zaunes in Bezug zur Straße kann man über die Site-Relation beschreiben. oder an den Straßen-Way sowas wie border:left=fence. Dafür direkt wieder ne Relation zu kreieren halte ich für sehr overdone. Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging der Seezeichen äußern. Vielleicht ist der eine oder andere Gedanke ja nützlich. Eine gute Definition der Tags ist wichtig. Unvollständige Wiki-Texte führen zu Mißverständnissen und später zu Streit. Irgendwann wird dann ein OSM-User behaupten, jedes schwimmende, algenbewachsene Objekt sei eine Lateraltonne grün. Namen sind Schall und Rauch. Ob eine Lateraltonne als buoy_lateral oder lateral_buoy definiert wird, ist zweitrangig. Wichtig ist, dass es eine eindeutige Beschreibung des Seezeichens bzw. der Ge- und Verbote eines Gewässerteils gibt. Dass das OSM-Datenschema mit der Norm IHO-S-57 korrespondiert, finde ich richtig. Die OSM-Tags müssen nicht exakt den IHO-Konventionen folgen. Eine eindeutige Zuordnung genügt. Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen (eine evangelische Kirche kann ich auch nicht ohne Hilfe korrekt eingeben). Für Leuchttürme mit Sektorenfeuer, die nicht sehr zahlreich sind, kann anderes gelten. Bereits vorhandene OSM-Tags (Fähre, boat, motorboat) sollten weiterbenutzt werden. Das DE:Tonne/Datenmodell von Olaf unter http://wiki.openstreetmap.org/wiki/DE:Tonne/Datenmodell gefällt mir recht gut. Die Tagnamen finde ich unnötig lang. Statt seamark:buoy_cardinal:name würde auch seamark:name genügen. OSM kommt sonst mit einem universellen name=* aus. Der lange Name ist umständlich zu tippen, passt möglicherweise nicht in jedes Textfeld, benötigt zusätzliche Abfragen in Renderern und Auswerteprogrammen. Zudem kann es zu Inkonsistenzen führen, wenn man ein seamark=buoy_safewater mit seamark:buoy_cardinal:name kombiniert. Ich würde Redundanz vermeiden. Wenn seamark=buoy_isolated_danger nur mir seamark:topmark:shape=2 spheres zu kombinieren ist, würde ein seamark:topmark=yes genügen. Zu Jans Vorschlägen unter http://www.freietonne.de/index.php?site=31infotyp=1printable=1 habe ich mich schon geäußert. Hauptkritikpunkt war, dass er strecken- oder flächenbezogene Verbote als Punktobjekte der Verbotsschilder taggen will. Er hat seine Konvention, in welcher Richtung ein Schild zu lesen ist, noch nicht erläutert. Häfen sind nicht einfach zu erfassen. Auf Übersichtskarten möchte man wahrscheinlich die wichtigen Handel-, Fähr und Militärhäfen als Punkt sehen, im mittleren Maßstab auch die Fischerei- und Yachthäfen und auf Detailkarten stört ein Hafenmittelpunkt. Dort möchte man die eher einzelnen Liegeplätze für die Großschiffahrt mit ihren Parametern sehen. Mir fehlen noch Tags für Markierungsbojen der Schwimmerbereiche (weißer Ball mit gelbem Kreuz), evtl. Nichtschwimmerbereichsbojen, Ankerbojen und dauerhafte Regattabojen. Ein Tag für Lichtsignalanlagen (typisch bei Schleusen, Klappbrücken, Kanalausweichstellen) wäre nützlich. Sehr wichtig ist ein Schema für Sperrgebiete, Warngebiete, Verbotszonen
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Hi Rolf. Wer behauptet denn, dass ich vom Schema der S-57 abweiche? Ihr solltet nur vor lauter kompliziertem Beschreibungskatalog nicht vergessen es auch einfach/logisch/nachvollziehbar zu halten. Klar kann man Details mit beliebig vielen Tags beschreiben, und das ist auch richtig so. Aber wenn nicht auch schon minimalste Infos eine Aussage haben, dann nützt das Schema nicht viel. Mit buoy=lateral_port kann man z.B. einer Tonne eine eindeutige Funktion geben ohne auch nur ein Detail zu kennen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging der Seezeichen äußern. Vielleicht ist der eine oder andere Gedanke ja nützlich. Eine gute Definition der Tags ist wichtig. Unvollständige Wiki-Texte führen zu Mißverständnissen und später zu Streit. Irgendwann wird dann ein OSM-User behaupten, jedes schwimmende, algenbewachsene Objekt sei eine Lateraltonne grün. Namen sind Schall und Rauch. Ob eine Lateraltonne als buoy_lateral oder lateral_buoy definiert wird, ist zweitrangig. Wichtig ist, dass es eine eindeutige Beschreibung des Seezeichens bzw. der Ge- und Verbote eines Gewässerteils gibt. Dass das OSM-Datenschema mit der Norm IHO-S-57 korrespondiert, finde ich richtig. Die OSM-Tags müssen nicht exakt den IHO-Konventionen folgen. Eine eindeutige Zuordnung genügt. Sprechende OSM-Namen (buoy_lateral) finde ich besser als Abkürzungen (BOYLAT). Die Tags sollten nicht unnötig lang sein. Alle Seezeichen sollten mit jedem OSM-Editor ohne Zusatzprogramme editierbar sein. Die Wiki-Beschreibung oder eine Kopie eines ähnlichen Objekts sollten als Vorlage genügen (eine evangelische Kirche kann ich auch nicht ohne Hilfe korrekt eingeben). Für Leuchttürme mit Sektorenfeuer, die nicht sehr zahlreich sind, kann anderes gelten. Bereits vorhandene OSM-Tags (Fähre, boat, motorboat) sollten weiterbenutzt werden. Das DE:Tonne/Datenmodell von Olaf unter http://wiki.openstreetmap.org/wiki/DE:Tonne/Datenmodell gefällt mir recht gut. Die Tagnamen finde ich unnötig lang. Statt seamark:buoy_cardinal:name würde auch seamark:name genügen. OSM kommt sonst mit einem universellen name=* aus. Der lange Name ist umständlich zu tippen, passt möglicherweise nicht in jedes Textfeld, benötigt zusätzliche Abfragen in Renderern und Auswerteprogrammen. Zudem kann es zu Inkonsistenzen führen, wenn man ein seamark=buoy_safewater mit seamark:buoy_cardinal:name kombiniert. Ich würde Redundanz vermeiden. Wenn seamark
Re: [Talk-de] Hauptwege auf Friedhöfen
André Riedel schrieb: Am 12. Juli 2009 10:22 schrieb malenki o...@malenki.ch: André Riedel schrieb: highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Dies gilt auch für highway=track, besonders für trackgrade=1 (Wirtschaftswege Co) Bei service stelle ich mir vor, dass da mehre PKW täglich langfahren und auch dürfen. Bei einem track stelle ich mir über das Jahr gesehen fast keinen Verkehr pro Tag vor, zumindest von der gesetzlich legalen Seite her. Da die Wege aber einfach breiter als was? auf allen Friedhöfen? sind und die Hauptnutzer Fussgänger sind, aber auch mal vom ^^ ansässigen Gärtner oder Friedhofsbetreiber benutzt werden können, sehe ich highway = track als die beste Variante. Ich nicht. Du sagst selbst: Hauptnutzer=Fußgänger Warum nicht highway=footway benutzen? diese sind normalerweise auch für Rollstuhlfahrer benutzbar. Die Oberflächenbeschaffenheit kann man mit surface=* angeben, die Breite mit width=* mit access kannst du angeben, wer/ws sich auf den Wegen bewegen darf. Ja das geht natürlich auch, beschreibt aber nicht, dass dort auch der Friedhofsgärtner mit seinem kleinen LKW langfahren kann. Mann kann dies nur mit motorcar = private umschreiben, aber in meiner Tag-Nutzung ist ein footway bzw. path nie oder nur in äußersten Ausnahmen mit PKW/LKW befahrbar. Desweiteren lässt sich dadurch eine gute Hierarchie zwischen Hauptwegen (track) und Wegen zu einzelnen Gräbern (path) abbilden. Ich kann mir nicht vorstellen, dass jemand, der auf dem Friedhof mit einem Kfz herumfahren muss, nicht weiß, ob dies möglich ist. Wenn ein Bestatter wirklich eine Fernfahrt mit Ziel=Friedhof erledigen muss, wird er auch wegen anderer Sachen mit den lokalen Verantwortlichen Kontakt aufnehmen müssen. Ich dachte bei highway = service auch eher an mehere km^2 große Friedhöfe, welche man vornehmlich in den USA findet. also bei uns sind die asphaltierten Wege (oft 6m und mehr breit) service, die breiteren Schotterwege track und die kleineren Wege path. Bei einem Serviceweg zu einem Bauernhof fahren doch auch nicht täglich Autos lang. Finde deine Definition also etwas schwammig. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hauptwege auf Friedhöfen
André Riedel schrieb: highway = service hat für mich den Hintergedanken, dass PKW/LKW wirklich öfter dort lang fahren. Ich würde dies daher nur für Straßen innerhalb des Friedhofs anwenden. Dies gilt auch für highway=track, besonders für trackgrade=1 (Wirtschaftswege Co) Bei service stelle ich mir vor, dass da mehre PKW täglich langfahren und auch dürfen. Bei einem track stelle ich mir über das Jahr gesehen fast keinen Verkehr pro Tag vor, zumindest von der gesetzlich legalen Seite her. also bei uns sind die asphaltierten Wege (oft 6m und mehr breit) service, die breiteren Schotterwege track und die kleineren Wege path. Bei einem Serviceweg zu einem Bauernhof fahren doch auch nicht täglich Autos lang. Finde deine Definition also etwas schwammig. Ja leider hat das Tagging-Schema da seine Lücken und Probleme, jedoch bin ich damit immer sehr gut ausgekommen. Achja der Weg zum Bauernhof wird wahrscheinlich nicht nur von Fussgängern benutzt und der Bauer/die Bäuerin werden wahrscheinlich auch öfters mit ihrem PKW darüber fahren. Für diese service-Wege gibt es übrigens noch das Attribut service = driveway also Zufahrt. Ich weiß nicht, wie frequentiert eure Friedhöfe sind, aber bei uns wird von Angehörigen aber eben auch von externen Gärtnern die Friedhöfe mit PKWs befahren um zu den entsprechenden Anliegen zu kommen. Diese Wege haben eindeutig einen service-Charakter. Nur muss man eben ggf. einen Schlagbaum passieren. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginschema für Signale- und Symboler fassung auf Wasserwegen
Der Denkfehler liegt aber dann bei euch. Denn OSM basiert darauf, dass der Detailgrad kontinuierlich gesteigert werden kann, aber auch schon die Basisinfo eine klare Aussage hat. Proprietäre Elitesysteme sind eigentlich nicht unser aller Ziel. Was ist bitte daran besser keine Tonne an einer Stelle zu haben als eine Tonne, die vielleicht noch nicht im Deatil beschrieben ist, aber trotzdem eine klare Aussage hat? Ich hab zum Navigieren doch lieber z.B. eine buoy=cardinal_north in der Karte als keine, nur weil noch kein Leuchtfeuer oder Topmark eingezeichnet ist... Wie gesagt. Details wie Form, Topmark und weitere aktive Signale sind auch wichtig zu erfassen. Ändern aber ja nix an der Richtigkeit der Grundfunktion. Aber um deine Frage zu beantworten. Hier ein Paar Beispiele:. foghorn=yes oder foghorn=horn oder foghorn=bell topmark=yes oder z.B. topmark=cylinder mit topmark:color=red light=yes oder light=red + light:category=quick (für z.B. Funkelfeuer) Das versteht jeder beschreibt den Sachverhalt und kann auch jeder wenns hart auf hart kommt manuel erfassen (ohne spezielle Editoren) Gruß Mario Rolf Meyerhof schrieb: Hi Mario Genau das ist der Denkfehler. Lieber keine Tonne, als eine Falsche oder unvollständig bezeichnete. Du verstehst nicht dass ein Editor, es eigentlich leichter macht, weil man diesen komplizierten Beschreibungsteil durch den Editor ausgefüllt bekommt. Und wo bleibt bei deinem Beispiel das mögliche Nebelhorn , das Leuchtfeuer und die Tonnengeometrie. Die werden doch dann nicht erfasst. Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Mario Salvini Gesendet: Sonntag, 12. Juli 2009 14:46 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Hi Rolf. Wer behauptet denn, dass ich vom Schema der S-57 abweiche? Ihr solltet nur vor lauter kompliziertem Beschreibungskatalog nicht vergessen es auch einfach/logisch/nachvollziehbar zu halten. Klar kann man Details mit beliebig vielen Tags beschreiben, und das ist auch richtig so. Aber wenn nicht auch schon minimalste Infos eine Aussage haben, dann nützt das Schema nicht viel. Mit buoy=lateral_port kann man z.B. einer Tonne eine eindeutige Funktion geben ohne auch nur ein Detail zu kennen. Gruß Mario Rolf Meyerhof schrieb: Hi Mario Leider ist mir nicht bekannt ob du Seemann bist oder nicht. Wenn ja solltest du bedenken das wir Seemänner später einmal nach diesen Eingaben navigieren wollen. Dazu sollten die Angaben so sicher und vollständig wie möglich sein. Das wird durch vollständige Abfragen in einem Editor sicherlich leichter erreicht. Ich kann eigentlich nicht vertreten wenn vom Schema der S-57 abgegangen wird. Mir geht hier nicht um meiner ist besser oder länger sondern um Qualität. Da die Infos schwierig einzugeben sind findest du bei OSeaM auch noch keine Flächendecken Daten. Gruß Rolf Hi Rolf, die Frage ist, ob man die Infos auch ohne euren Editor einfach eingeben kann. Und das ist momentan noch bei keinem richtig gegeben ( weder OseaM (also euch) noch bei FT). Finde also solche meiner is besser/länger als beim Anderen eher kontroproduktiv für die Diskussion. Auch find ichs schade, dass du meinen Vorschlag (den eines Fraktionslosen) gekonnt zu überlesen/ignorieren scheinst. Gerade da hätte ich von euch Input/Kommentare erhofft. Gruß Mario Rolf Meyerhof schrieb: Hallo Stephan Siehe Dir doch einmal die Unterschiede an. Bei Jan gibt es für jede Tonne mit jeder Farbe und jedem Kopfzeichen ein Symbol das beim tagging ausgewählt werden muß. Bei Olaf gibt es einen Editor in dem man die Tonnen Symbole, die Farbe, das Kopfzeichen, die Befeuerung und das Nebelhorn in einer Maske auswählen kann. Was ist einfacher? Probier es einfach einmal aus. Ein Testmodell des Editors läuft bereits. Hier der Link http://wiki.openstreetmap.org/wiki/DE:Seamap-Online-Editor Gruß Rolf -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Stephan Wolff Gesendet: Sonntag, 12. Juli 2009 03:45 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Tagginschema für Signale- und Symbolerfassung auf Wasserwegen Mario Salvini schrieb: als Neutraler starte ich hier mal die Diskussion, wie man Boyen, Tonnen, Leuchtfeuer, und alles andere was für eine Seekarte und andere intereesant werden könnte/sollte erfasst werden soll. Ich bin an einer OSM basierten Seekarte sehr interessiert, aber ich kann bis auf die Erfassung einiger Seezeichen wenig beitragen. Jan, Markus und Olaf (in alphabetischer Reihenfolge, ohne Wertung) haben sehr viel mehr geleistet, so dass ihnen das Vorschlagsrecht zusteht. Ich werde trotzdem mal meine Ideen zum Tagging
