Re: [Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)
Am 4. November 2014 17:21 schrieb Markus liste12a4...@gmx.de: Gedanken zu https://lists.openstreetmap.org/pipermail/tagging/2014-October/019775.html Dort wird diskutiert, ob man eine Bucht als Punkt oder als Fläche kartografieren soll ;-) für Punkt: - ist viel einfacher einzutragen - ungefähr in der Mitte für Fläche: - eine Bucht ist eine Fläche - nur so kann man die Ausdehnung bestimmen und weiterhin für die Fläche: - so kann man die Lage genau bestimmen - so kann man die Hierarchie erkennen (Bucht in Bucht) gegen Fläche: - unscharfe Objekte können nicht sinnvoll begrenzt werden - mapping für den Renderer: wo der Schriftzug hin soll das ist eher gegen den Node als gegen die Fläche vorzubringen m.E. - hierarchische Zusammenhänge erforden viele Flächen in Flächen Relationen sind noch komplizierter das ist auch kein Punkt gegen die Fläche, weil es mit dem Node gar nicht geht, oder nur mit Relationen, die Du ja auch nicht willst. Gedanken dazu: _Unscharfe Objekte_ Berge, Gebirge, Buchten, Meeresteile, Meeresstrassen zw. Inseln, geogr. Gebiete, Täler, Wüsten, Sumpfgebiete, Wattgebiete, etc. sind immer unscharf, da ihre Beschreibung künstlich ist. jein, es gibt öfters auch scharfe Grenzen Scharfe und unscharfe Objekte sind verschiedene Klassen. Sie sollten nie vermischt werden. kannst Du das erklären? Wäre die Schlussfolgerung, alle Buchten wieder rauszulöschen aus OSM? Ist ein Punkt für Dich ein scharfes oder unscharfes Objekt? Die Küstenlinie umzudefinieren als Grenze einer Bucht ist m.E. eine Klassen-Verletzung und auch sachlich nicht richtig. darum geht es nicht, es soll nicht die Küstenlinie umdefiniert werden, sondern der Küstenteil, der auch die Bucht begrenzt, soll verwendet werden, um die Bucht zu beschreiben. Das ist bei Node und Fläche der Fall. Vielleicht könnte man für unscharfe Objekte alternativ in der DB einen eigenen Layer machen, in dem Dinge wie Kieler Bucht, Ural, Allgäu, Golf von Aden, etc. ungefähr als Fläche eingezeichnet werden? Das könnte ganz grob gezeichnet werden und würde Grösse und Form trotzdem gut abbilden. sowas hatte ich vor 3 Jahren auch mal vorgeschlagen, gemeinsam z.B. von einem Shapefile von NaturalEarth ausgehend einen grobmaßstäblichen Shapefilelayer mit Namen in allen zugänglichen Sprachen (oder z.B. Wikidata-Referenzen) zu entwickeln, einen Paralleldatensatz der bei Bedarf dazugemischt werden kann. https://lists.openstreetmap.org/pipermail/talk-de/2011-August/088514.html Leider gab es darauf damals überhaupt keine Antwort, weder zu den technischen Fragen noch inhaltlich, vielleicht ist das aber mittlerweile anders? Gäbe es Leute die an so was Spass hätten? Ein bisschen was findet sich auch hier: http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.de/94163 http://comments.gmane.org/gmane.comp.gis.openstreetmap.region.de/88538 _Küstenzonenmanagement_ Die Hydrographischen Organisationen verschieben ihren Schwerpunkt Richtung Meeresumweltschutz, Küstenzonenmanagement und maritime Raumordnung: https://www.facebook.com/OpenSeaMap Zonen werden bezeichnet für: - Küstenschutz - Umweltschutz - Baumassnahmen - Windpark - Geschwindigkeitsbegrenzung - Zoll- und Polizei-Zuständigkeit - Fischfangbestimmungen - Artenschutz - Tourismus - Naturschutz - politische Zuständigkeiten - Wasserqualität - Abfallbeseitigung - Strömungen - Ankerplätze - Tauchgebiete - Schiessplätze - Ausgrabungsstätten etc. etc. Jede Zone hat eine Bezeichnung und weitere Attribute. _Lösungsvorschlag_ Spezieller *DB-Layer für unscharfe Objekte* Spezieller Editor (oder Tool in JOSM) diese Küstenzonen sind m.E. administrative Gebiete, und höchstwahrscheinlich sind die nicht unscharf sondern am Reißbrett gezogen (nicht wörtlich ;-) ). Vermutlich ein Fall für boundaries in OSM (falls man das alles will, und es nicht sowieso dasselbe ist wie die Ländergrenzen). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 4. November 2014 18:18 schrieb fly lowfligh...@googlemail.com: Jain, forward/backward funktioniert nicht direction=* in Himmelrichtungen bzw Winkel geht sehr gut wenn man die tatsächlichen Werte dieses Keys betrachtet ist allerdings clockwise mit Abstand der häufigste Wert, danach kommen forward und backward ;-) http://taginfo.openstreetmap.org/keys/direction#values Alternativ vielleicht auch orientation? Fände ich sprachlich besser, kommt aber nur 350mal vor bisher, dafür mit augenscheinlich konsistenteren Werten: http://taginfo.openstreetmap.org/keys/orientation#values fast 90K mal gibt es die roof:orientation Variante, die dafür andere Werte hat: http://taginfo.openstreetmap.org/keys/roof%3Aorientation#values Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)
On Tuesday 04 November 2014, Markus wrote: Liebe DB-Designer, mein Englisch ist nicht so gut - vielleicht kann das ja jemand auf talk weitergeben, als Gedanken zu https://lists.openstreetmap.org/pipermail/tagging/2014-October/019775 .html Ich glaube, dass die Diskussion hier weitgehend an den eigentlich für Meeresteile relevanten Fragen vorbei geht. Unscharfe Grenzen sind dabei nur ein Teil des Problems. Was ich bei den Befürwortern der Erfassung als Polygon im allgemeinen beobachte sind zwei Dinge: - Oft sind dies primär Daten-Anwender und eher selten Mapper. Die Tatsache, dass die tatsächliche Erfassung von Buchten zu über 90 Prozent als Punkte erfolgt spricht hier eigentlich für sich. Für den Anwender ist fast immer ein Polygon schöner, denn es lässt sich - falls notwendig - ganz einfach auf einen Punkt reduzieren und ein Polygon erspart dem Anwender oft zusätzliche Arbeit (auf Kosten von Mehrarbeit für den Mapper natürlich). Der aktuelle Anlass für die Diskussion in Tagging war ja auch, dass Mateusz Konieczny für die Beschriftung in der Karte gerne die Bucht-Fläche als Bedeutungs-Maßstab heranziehen wollte. Man könnte zwar bei Punkten stattdessen ohne weiteres auch den Abstand des Punktes zur Küstenlinie verwenden, die Küstenlinien werden nur derzeit nicht in die Rendering-Datenbank importiert (sie werden standardmäßig von osm2pgsql herausgefiltert). - Es gibt verbreitet eine recht dogmatische Haltung, dass sich alles, was erfasst wird, auf die drei geometrischen Grundtypen Punkt, Linie und Polygon reduzieren lassen muss. Zweidimensionale Dinge wie es Buchten nun einmal sind müssen entsprechend dieses Schemas als Polygone erfasst werden. Meine Befürwortung der Erfassung als Punkt resultiert in erster Linie aus der Tatsache, dass in einem Polygon in diesem Fall meist kein nennenswerter zusätzlicher Informationswert steckt. Ein Polygon zu haben bedeutet bestenfalls einen geringen Bequemlichkeitsgewinn für den Anwender, in jedem Fall aber einen erheblichen Mehraufwand für den Mapper. Meine Befürchtung ist in erster Linie, dass falls sich die Erfassung als Multipolygone tatsächlich durchsetzen sollte wir sehr schnell zu einem Zustand wie bei den Grenz-Relationen kommen, nämlich dass ein Großteil der Mapper aufgrund der Komplexität einen weiten Bogen darum machen. Das wäre meines Erachtens das schlechteste aller möglichen Ergebnisse. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: Unnötige Aufteilung in platform und stop_postion
On 05.11.2014 06:08, Tirkon wrote: [...] +1 -- Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)
Hallo Martin, Ein Fehler in der engl. Diskussion ist m.E., dass dort nach einem Tagging für den Renderer gesucht wird (genauer: für die Beschriftung von unscharfen Gebilden in der Karte). Und dabei die geografischen Fragen ausser acht gelassen werden. Stattdessen wird dann gestritten darüber, ob etwas einfach oder kompliziert sei - jeweils aus unterschiedlichen Sichtweisen ;-) Ein Missverständnis in der engl. Diskussion scheint mir, dass Punkt und Fläche als geometrische Elemente verwechselt werden mit Punkt und Fläche als Repräsentanz für unscharfe geografische Gebilde oder gar als Repräsentanz zur kartografischen Lokalisierung eines Namenszuges eines unscharfen geografischen Gebildes. Dass weder geometrischer Punkt noch geometrische Fläche ein unscharfes Gebilde geometrisch beschreiben können, dürfte aber doch klar sein? M.E. darf die Klasse der scharfen Objekte (die geometrisch eindeutig beschrieben werden können, und deren Grenzen in der Wirklichkeit deutlich sichtbar sind) - nicht vermischt werden mir der Klasse der unscharfen Gebilde (die geometrisch nicht eindeutig beschrieben werden können, und deren Grenzen in der Wirklichkeit nicht sichtbar sind). Ich glaube, dass der durchschnittliche Mapper nicht unterscheiden kann, ob eine Linie ein geometrisches Element darstellt oder nur Repräsentanz ist für ein unscharfes Gebilde. Deshalb die Idee, unscharfe Gebilde in einer neuen zusätzlichen Ebene der DB zu erfassen, getrennt von den geometrischen Objekten, aber denoch in einem räumlichen Bezug zu ihnen. Du hattest mal vorgeschlagen, dafür eine Extra-DB einzurichten. Da wir in der DB bisher nur geometrische Elemente kennen (Punkt, Linie, Fläche) plus Relationen dieser Elemente, und ich keine Idee habe, wie man nichtgeometrische Elemente beschreiben könnte, schlage ich vor Flächen zu missbrauchen als Repräsentanz für unscharfe Gebilde, und diese in eine zweiten DB-Ebene dergestalt zu isolieren, dass die nicht geometrisch verbunden werden können mit den geometrischen Punkten, Linien und Flächen aus der jetzigen DB-Ebene. Eine *Bucht* als unscharfes Gebilde ist dann nicht verbunden mit einer Küstenlinie (die übrigens auch nur zu einem bestimmten Zeitpunkt scharf ist, und sich vorher und nachher mit Welle, Tide und Erosion permanent ändert). Eine Bucht endet nicht an der landseitigen Wasserlinie. Nur die Wasserfläche der Bucht endet an der landseitigen Wasserlinie. Aber die landseitige Wasserlinie ist nicht identisch mit der Bucht. Die Bucht endet je nach Sicht des Betrachters: an der Küstenstrasse, an der inneren (oder äusseren) Grenze der Bebauungszone, am Hang der umgebenden Hügel/Berge, auf der Tiefenlinie die dem Tiefgang des eigenen Schiffes entspricht, etc. Eine Bucht ist auch landseitig unscharf. Seeseitig ist eine Bucht ebenfalls unscharf. Sie endet irgendwo zwischen zwei (oder mehreren) markanten Punkten. Wo diese Punkte liegen, und wie sie miteinander verbunden werden, ist immer abhängig von der Sicht des Betrachters. Manchmal hingegen werden seeseitige Grenzen festgelegt. Dann handelt es sich aber um eine definierte und festgeschriebene Grenze, wie beispielsweise die Basislinie zur Bestimmung der seeseitigen Staatsgrenze. Ich meine, es wäre sinnvoll, die Frage der Repräsentanz unscharfer Gebilde hier einmal grundsätzlich anzugehen und zu lösen :-) Ein *Berg* als unscharfes Gebilde besteht aus einem Gipfel als Punkt, und irgendetwas drumherum das irgendwie eher einer Fläche entspricht, aber halt nicht genau begrenzt ist. Ein Berg ist auch nicht durch Flüsse begrenzt (denn Flüsse fliessen in einem Tal, und ein Tal gehört nicht zum Berg). Ein Berg geht soweit, bis ein anderer Berg mit dessen Ausdehnung zur eigenen Ausdehnung in Konflikt kommt. Oder bis sein Fuss in ein Tal übergeht. Das hat etwas zu tun mit Mächtigkeit: Gipfelhöhe, Gipfelform, Dominanz, Reliefenergie, Schartenhöhe, Flankensteilheit, ist-Teil-von, Entfernung-von, etc. Was ein Berg ist, kann m.E. nur durch (meist relative) Parameter beschrieben werden - aber nicht geometrisch. Einige der Parameter könnte man an eine angenäherte Fläche koppeln, und andere Parameter könnte man vermutlich relativ zu den Flächen untereinander berechnen (so wie Christoph das vorschlägt). _DB-Ebene für unscharfe Gebilde_ Ob so eine DB-Ebene für unscharfe Gebilde eine methodisch sinnvolle Lösung ist - ober ob es noch etwas viel Sinnvolleres gibt - weiss ich nicht. Technisch machbar scheint es aber zu sein... Scharfe Objekte und unscharfe Gebilde sind verschiedene Klassen. Sie sollten nie vermischt werden. kannst Du das erklären? Hoffe es ist jetzt etwas klarer? Wäre die Schlussfolgerung, alle Buchten wieder rauszulöschen aus OSM? Nein, sondern sie zu überführen in eine DB-Ebene für unscharfe Gebilde. sowas hatte ich vor 3 Jahren auch mal vorgeschlagen, gemeinsam z.B. von einem Shapefile von NaturalEarth ausgehend einen grobmaßstäblichen Shapefilelayer mit Namen in allen
Re: [Talk-de] priority=* an railway=*
Am 04.11.2014 um 20:15 schrieb Michael Reichert: Hallo Fly, Am 2014-11-04 um 18:48 schrieb fly: Dachte, die wären doch zu Google gegangen. Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im Vorhinein zu diskutieren ist. http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000157.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000159.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000164.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000165.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000166.html Danke, aber sowas gehört doch auch auf eine offizielle Mailingliste wie transit@ oder tagging@ Auch auf dieser Liste hätte ja zumindest ein Link zur Diskussion mitgeteilt werden können. Bei wievielen Mailinglisten soll ich mich denn sonst noch überall anmelden ? Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Am 05.11.2014 um 12:53 schrieb Martin Koppenhoefer: Am 4. November 2014 18:18 schrieb fly lowfligh...@googlemail.com: Jain, forward/backward funktioniert nicht direction=* in Himmelrichtungen bzw Winkel geht sehr gut wenn man die tatsächlichen Werte dieses Keys betrachtet ist allerdings clockwise mit Abstand der häufigste Wert, danach kommen forward und backward ;-) https://taginfo.openstreetmap.org/keys/direction#values Wir reden wohl eher von Punkten: https://taginfo.openstreetmap.org/keys/direction?filter=nodes#values clockwise kommt durch junction=roundabout forward/backward wurde mal gehipt und wird immer noch von Vorlagen unterstützt. Auch steht es an mehreren Stellen im wiki (zb. traffic_sign). Im Moment wird es von openrailway-tagging verwendet macht aber auch da keinen Sinn und ist extrem Fehler anfällig, da weder die Richtung der Linie umgedreht werden darf noch die Linie an diesem Punkt geteilt werden darf. Alles in allem kannst Du bei absoluten Werten hier wohl eher nur die Werte von forward+backward mit allen Werten mit Grad + Himmelrichtungen vergleichen Alternativ vielleicht auch orientation? Fände ich sprachlich besser, kommt aber nur 350mal vor bisher, dafür mit augenscheinlich konsistenteren Werten: https://taginfo.openstreetmap.org/keys/orientation#values Wohl eher beim Luftverkehr verwendet. fast 90K mal gibt es die roof:orientation Variante, die dafür andere Werte hat: https://taginfo.openstreetmap.org/keys/roof%3Aorientation#values Hat auch 90% along bzw across als Wert. Sorry, überzeugen mich beide nicht so wirklich. Denke das Hauptproblem war die Wikiseite, wo viel zu lange forward/backward ganz oben stand. Zur Zeit fehlt immernoch ein Hinweis, dass diese Werte an Punkten von keiner Edit-Software unterstützt werden. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)
Am 5. November 2014 14:20 schrieb Markus liste12a4...@gmx.de: Hallo Martin, Ein Fehler in der engl. Diskussion ist m.E., dass dort nach einem Tagging für den Renderer gesucht wird (genauer: für die Beschriftung von unscharfen Gebilden in der Karte). Und dabei die geografischen Fragen ausser acht gelassen werden. sehe ich nicht so Dass weder geometrischer Punkt noch geometrische Fläche ein unscharfes Gebilde geometrisch beschreiben können, dürfte aber doch klar sein? sofern es eine geometrische Beschreibung des unscharfen Gebildes gibt, wird man sowohl mit Punkt(en) als auch mit Fläche(n) eine Näherung erreichen können. M.E. darf die Klasse der scharfen Objekte (die geometrisch eindeutig beschrieben werden können, und deren Grenzen in der Wirklichkeit deutlich sichtbar sind) - nicht vermischt werden mir der Klasse der unscharfen Gebilde (die geometrisch nicht eindeutig beschrieben werden können, und deren Grenzen in der Wirklichkeit nicht sichtbar sind). sind ja nicht vermischt, da durch die tags klar ist, was jeweils beschrieben wird. Deshalb die Idee, unscharfe Gebilde in einer neuen zusätzlichen Ebene der DB zu erfassen, getrennt von den geometrischen Objekten, aber denoch in einem räumlichen Bezug zu ihnen. Du hattest mal vorgeschlagen, dafür eine Extra-DB einzurichten. Da wir in der DB bisher nur geometrische Elemente kennen (Punkt, Linie, Fläche) plus Relationen dieser Elemente, und ich keine Idee habe, wie man nichtgeometrische Elemente beschreiben könnte, schlage ich vor Flächen zu missbrauchen als Repräsentanz für unscharfe Gebilde, und diese in eine zweiten DB-Ebene dergestalt zu isolieren, dass die nicht geometrisch verbunden werden können mit den geometrischen Punkten, Linien und Flächen aus der jetzigen DB-Ebene. weiter oben hattest Du doch geschrieben, dass das Deiner Ansicht nach gar nicht geht? Was z.B. ginge wäre eine Beschreibung über mehrere Grenzen, sozusagen eine Maximal- und eine Minimalversion bzw. eine Annäherung daran. Dazwischen befände sich dann irgendwo die Wahrheit. Ein *Berg* als unscharfes Gebilde besteht aus einem Gipfel als Punkt, und irgendetwas drumherum das irgendwie eher einer Fläche entspricht, aber halt nicht genau begrenzt ist. Was ein Berg ist, kann m.E. nur durch (meist relative) Parameter beschrieben werden - aber nicht geometrisch. vielleicht sollten wir das als Hinweis aufnehmen, um eben auch nur das zu kartieren, was klar ist (z.B. Gipfel) und akzeptieren, dass die unklaren Dinge bzw. die, die man subjektiv definieren muss, bei uns keinen Platz haben sollten? Wäre die Schlussfolgerung, alle Buchten wieder rauszulöschen aus OSM? Nein, sondern sie zu überführen in eine DB-Ebene für unscharfe Gebilde. das ist ungefähr dasselbe. Wenn der Bezug nur räumlich ist, dann ist es egal, ob das diesselbe oder eine andere db ist. Erwähnt habe ich das, weil es eine weitere, zusätzliche Dimension ist, die uns bei OSM beschäftigen wird: *virtuelle Grenzen* - die in der Wirklichkeit nicht sichtbar sind. das ist nichts neues, davon haben wir schon einige (admin boundaries, Nationalparks etc.) Wir haben auch sonst viele Attribute, die nicht immer vor Ort beobachtbar sind, z.B. wikipedia links, start_date, old_name etc. Anders als Staatsgrenzen und deren hierarchischen Sub-Formen (die vielfach auch virtuell sind und nicht durch Grenzsteine markiert, und die wir in OSM trotzdem eintragen) sind Grenzen aus dem Küstenzonenmanagement nur ein Teil vieler und exponentiell zunehmender virtueller Grenzen. da ist nichts anders, ausser vielleicht dass das allgemeine Interesse an speziellen Küstenzonengrenzen geringer sein dürfte, was auch gewisse Auswirkungen hat. c) gemischt mal eigenständig mal drangekebt werden (wie bei den Buchten) bei den Buchten wird normalerweise nichts geklebt, da wird (sofern man nicht Polygone überlappt, was insbesondere bei umfangreichen Polygonen ziemlich archaisch ist) die Küstenlinie als Begrenzung an der Landseite (d.h. als outer eines Multipolygons) verwendet. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Falls das nicht rüberkam in meiner Mail, ich wollte sagen, dass obwohl Richtungswerte (NSOW, Gradzahlen) bisher noch in der Unterzahl sind, ich diese Variante für sinnvoll halte. Am 5. November 2014 15:59 schrieb fly lowfligh...@googlemail.com: Zur Zeit fehlt immernoch ein Hinweis, dass diese Werte an Punkten von keiner Edit-Software unterstützt werden. der Hinweis sollte m.E. noch eindeutiger sein und explizit klar stellen, dass vorwärts und rückwärts auf einem Punkt normalerweise keinen Sinn machen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unscharfe Objekte (Bucht, Berg, Gebiet, Kanal, Meeresteil, etc)
Am 4. November 2014 17:21 schrieb Markus liste12a4...@gmx.de: Jede Zone hat eine Bezeichnung und weitere Attribute. _Lösungsvorschlag_ Spezieller *DB-Layer für unscharfe Objekte* Spezieller Editor (oder Tool in JOSM) Mein Vorschlag, den ich schon mal an anderer Stelle hier auf der Liste unterbreitete: Aus meiner Sich muss man erst einmal unterscheiden, ob es sich um genau umgrenztes gebiet handelt oder um ein Gebiet mit fließenden Übergängen. Für gebiete mit fließenden Übergängen ist es m.E. ausreichend und vor allem Sinnvoll, wenn man einzelne Tags in der Art is_in:zonenbezeichnung=value an schon vorhandene Nodes und Ways setzt. Dann kann man zwar aus der Datenbank nicht unmittelbar fertige Zonen extrahieren, aber schöne Punktewolken, anhand deren Verteilung man dann die Ausdehnung des Gebietes bestimmen kann. Also zum Beispiel könnte die Nodes der Küstenlinie der Deutschen Bucht is_in:bight=Deutsche Bucht bekommen genau so wie Tonnen, die in der Deutschen Bucht liegen etc. aus der Verteilung dieses Tags könnte man dann die Ausdehnung der Deutschen bucht als Fläche bestimmen. Oder wenn gar nichts anderes hilft ein is_in:sea_area=value. Wobei value immer eine Name ist. aus einem tag lassen sich mehrere Informationen ableiten: 1. die Gattung: sea_area, bight, etc. 2. der Name des Gebietes, 3. die Ausdehnung des Gebietes. Das Schema würde m.E. sogar funktionieren, wenn man im Schema auf die Gattungsbezeichnung verzichtet. Dann bekommt man immer noch die Info hier ist ein Gebiet mit ungefähr der Ausdehnung, dass den Namen XYZ trägt. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] priority=* an railway=*
On Mi, 2014-11-05 at 15:38 +0100, fly wrote: Am 04.11.2014 um 20:15 schrieb Michael Reichert: Hallo Fly, Am 2014-11-04 um 18:48 schrieb fly: Dachte, die wären doch zu Google gegangen. Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im Vorhinein zu diskutieren ist. http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000157.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000159.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000164.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000165.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000166.html Danke, aber sowas gehört doch auch auf eine offizielle Mailingliste wie transit@ oder tagging@ Auch auf dieser Liste hätte ja zumindest ein Link zur Diskussion mitgeteilt werden können. Bei wievielen Mailinglisten soll ich mich denn sonst noch überall anmelden ? Rückfrage: Auf wie vielen verschiedenen Kanälen soll denn nun über Eisenbahntagging diskutiert werden? Wer an Eisenbahnthemen in OSM interessiert ist, dürfte meist ohnehin bei der ORM-Mailingliste angemeldet sein. Der Sinn der ORM-Mailingliste ist es ja, Eisenbahnthemen unter interessierten Mappern zu diskutieren. transit und tagging sind für solche Themen nicht wirklich geeignet. Unabhängig davon sehe ich im vorliegenden Fall auch überhaupt keinen Grund, das Thema auf den genannten Mailinglisten anzusprechen. Statt eines etablierten und vieldiskutierten Taggingschemas hat Mentz - warum auch immer - ein veraltetes und ungeeignetes Taggingschema angewendet. Ich sehe bei dem Thema keinen Diskussionsbedarf mehr... Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 224 28.11.–3.11.2014
Hallo, die Wochennotiz Nr. 224 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/11/wochennotiz-nr-224/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
