Re: [Talk-de] Netbook-Anwender gesucht
Am 7. November 2010 11:41 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 07.11.2010 10:50, schrieb M∡rtin Koppenhoefer: Hmmm, ist wohl zu faul mir überhaupt die problematischen Menüs zu nennen, welche Auflösung oder welches System er hat. Ich hatte gedacht, dass es a) keine Rolle spielt, welche Auflösung es ist, da ich das Problem sowohl bei 1024x600 als auch bei 1376x1024 habe. Ich habe versucht, das Thema so kurz wie möglich zu beschreiben, weil ich dann den Entwicklern am wenigsten Zeit raube, aber nach Deinem Hinweis habe ich nochmal ein paar Angaben ergänzt. Das ganze passiert unter JAVA, Sun auf Ubuntu 10.04. Wieder so ein blödes Menuproblem, da gibt es bestimmt noch interessantere Tickets die ich mir mal anschauen kann ... klar, ist nur ein Hinweis, dass da was nicht funktioniert, und dass man daher die Software nur eingeschränkt nutzen kann, vor allem als Anfänger, wo man die shortcuts nicht kennt. Keine Forderung, das schnell zu beheben, erst recht nicht an Entwickler, die das Thema Menus nicht interessiert. Schon besser wäre: some menu-items are not accessible if menu height vertical screen resolution. I'm using Win XP with a 1024*768 screen where e.g. the last 3 items of the File menu are not accessible (I've attached a screenshot). ich weiss nicht, wie viele Items mir fehlen, weil ich sie nicht sehe. Die Screenauflösungen habe ich ergänzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 7. November 2010 18:46 schrieb Carsten Moeller cmindivid...@gmx.de: Am 07.11.2010 11:58, schrieb aighes: Hallo, hast du auch die highway=service rausgerechnet, die ein service=parking_aisle bzw. alley haben? Viele Grüße, aighes Hab jetzt mal 'n bisschen mehr ausgeklammert. Komme jetzt auf: 754.631 parking_aisle und driveway sind ziemlich sicher OK, alley ist ja aber gerade eine Straße, von daher würde ich die gar nicht unbedingt rausnehmen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 7. November 2010 18:30 schrieb Carsten Schönert c.schoen...@t-online.de: Am 07.11.2010 13:16, schrieb M∡rtin Koppenhoefer: setzt): bei einem Maxspeed, aber auch bei einem gesperrt für Fzg. aller Art, ist es oft nämlich nicht genau klar, bis wo das Schild wirklich gilt, dann hilft ein Blick in die StVO :-) das stimmt nicht. Wenn beispielsweise ein Z250 oder 260 (gesperrt für alle od. Kfz) nur auf einer Seite einer Straße steht, auf der anderen aber nicht, ist es keineswegs klar, ob man den kompletten Way damit taggen sollte. Das Schild zu taggen ist dagegen eindeutig und hilft den nachkommenden Mappern ungemein bei der Beurteilung der Situation, vor allem wenn sie aus der anderen Richtung die Straße genommen haben und das Schild evlt. gar nicht bemerkt haben. Hast Du mal die genaue Stelle in der StVO zu den Tempolimits? M.E. steht das da nicht so drin. Das Schild ergibt sich von selbst wenn ein Router die Nodes mit der Start- und der Endposition findet. Dann wäre eine weitere Info wegen dem Schild einfach nur unnötige Daten. jaja, so habe ich früher auch gedacht. Je mehr Tempolimits Du erfasst, um so mehr wirst Du es schätzen, wenn da solche Hinweise zu aufgestellten Zeichen in den Daten sind, erst recht an Stellen, wo die Limits assymetrisch sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=Leitplanke
Am 7. November 2010 19:11 schrieb René Falk li...@falconaerie.de: Folgende Werte habe ich schon gesehen: crash_barrier (Englische Bezeichnung in UK) guard_rail (Englische Bezeichnung in den USA) Leitplanke taginfo: guard_rail 201 guardrail 10 crash_barrier 8 ich nutze bisher auch guard_rail, allerdings in Unkenntnis, dass es ein amerikanisches Wort ist. Sind wir uns da sicher, dass man in GB nur crash_barrier verwendet? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 5. November 2010 18:45 schrieb tshrub my-email-confirmat...@online.de: für eine Ansammlung von Bäumen, die kein Wald ist? landuse=forest die _Größe_ (Fläche) macht den Wald ... bei landcover auch nicht anders. landcover=tree sagt, dass da Bäume sind, landuse=forest sagt, dass da ein Wald ist. Semantisch ist das so. Warum sollte man Flächen, die keine Wälder sind, als Wald taggen? Damit sie gerendert werden? Ein anderer Grund fällt mir eigentlich nicht ein. Für sand am Strand? natural=beach (meist naturdominiert, ausser einigen künstlich erhaltenen für Touris) das sagt aus, dass da ein Strand ist. Mit Sand hat das nichts zu tun. Für Fels am Strand? natural=rock? das sagt wiederum aus, dass da Felsen sind, hat nichts mit Strand zu tun. Für Wälder wo keine Bäume wachsen (landuse=forest, landcover=scrubs), Niederwald ist landuse=scrub oder natural=scrub (natürliche Extremstandorte) ich spreche nicht von Niederwald sondern z.B. von abgeholzten Wäldern oder Sturmschäden. für Grassflächen, die keine Wiesen sind, hatten wir oben in einem Thread, ich denk, das war landuse=grassland m.E. kein landuse. Landuse=verkehrsinsel (od. generischer: Nebenfläche Straße oder so). und landuse=meadow für die Wiese ja, das ist klar. Ging ja aber um Gras, das keine Wiese ist. um die Bodenbedeckung zu klären, etc. Für Micromapping in der Stadt ist es natürlich auch geeignet. na ja. da denkt ich wieder wenigern an _land_cover - das wäre übertrieben ;) m.E. nicht surface oder material wäre da naheliegender - in Verbindung mit einem Elterntag. kann man natürlich auch tun. Wenn man Jochens Argumentation folgt, wäre das aber die Nutzung desselben Tags in anderen Kontexten, die er nicht für gut hält. landuse sollte m.E. die Bodennutzung beschreiben, landcover die Bodenbedeckung, und natural bleibt für die geografischen features. landuse = Bodennutzung (meadow, field, forest, residential, ...) ja landcover = Bodenbedeckung (gras, vegetables, trees, garden, ...) vegetables ist wohl schon ein bisschen zu speziell für den Hauptvalue. Garden ist m.E. ein landuse. natural = geografische features (bog, ?, conifers, Rosengarten, ...) bog ist auch wieder zu speziell, das heisst mittlerweile ja wetland mit subtags, könnte evtl. auch landcover sein? Conifers sind landcover (Unterklasse von tree), Rosengarten wäre landuse, natural bleibt sowas wie Gipfel, Klippe, Strand, Wüste, Bucht, Höhleneingang, ... wäre irgendwie machbar, aber überzeugt mich noch nicht richtig. dann sieh es Dir nochmal mit den Kommentaren oben an, Deine Beispiele überzeugen mich auch nicht ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 5. November 2010 20:04 schrieb Schlauchboot schlauchboo...@googlemail.com: Am Freitag, 5. November 2010, 10:08:48 schrieb M∡rtin Koppenhoefer: Osmarender wertet width für Flüsse aus. das ist was ziemlich anderes und kartographisch üblich. Es würde mich stark wundern, wenn das eine allgemeine Aussage ist. Das hängt doch vom Sinn und Zweck der jeweiligen Karte ab. Straßen sind i.d.R. so wichtig, daß man die immer sehen will und die Breite damit abhängig vom Maßstab überzeichnen muß. Spezialkarten für Gewässer sollten dasselbe für diese tun, oder? Beispiele? Spezialkarten für Gewässer machen eigentlich was anderes: sie stellen nur die Gewässer dar. Klar. wenn die Breite einer Linie unterhalb die Darstellungsgrenze rutschen würde, macht man sie dünn, aber nicht maßstäblich. Strichstärken sind allgemein Symbole, die Aussage oben bezieht sich auf Flüsse, die breiter sind als der vorgesehene Strich, die macht man dann real breit. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage bezüglich Landes-, Stadt- und St adteilgrenzen
Am 5. November 2010 20:35 schrieb Florian Lohoff f...@zz.de: kann sein das sie Deckungsgleich sind - aber dann sollten die nur einmal existieren. Das ist gegenwärtig so festgelegt, ich weiss. Aber ist das eigentlich sinnvoll, oder ist es Mappen um es den Renderern leicht zu machen? Diese Art des Mappens erfordert vom Auswerter ja, dass er weiss, dass admin 4 und 6 od. 8 deckungsgleich sind. In der Karte sieht man das nicht, könnte genausogut sein, dass die level 6/8 fehlen. Wenn man beides hätte würde man ausdrücken, dass sie deckungsgleich sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Marktflächen/Parkplätze
Am 5. November 2010 22:35 schrieb Wolfgang wolfg...@ivkasogis.de: Hallo, in Hamburg gibt es viele Marktfächen, die zu Nicht-Marktzeiten als Parkflächen genutzt werden. amenity=markingplace;parking ? diese zeitlichen Überlappungen sind grundsätzlich in OSM derzeit kaum abbildbar. Wenn Du sowas wie das oben vorgeschlagene machts (marketplace), dann würde ich zusätzlich die Zeiten für beides angeben: marketplace:opening_hours= parking:opening_hours= ggf. wäre auch service_times besser? parking:opening_hours würde man vermutlich eher so interpretieren, dass man zu diesen Zeiten an sein Auto kommt (z.B. in einem Parkhaus), während man vermutlich erwarten würde, dass man das Auto in der übrigen Zeit zwar dort stehen lassen kann, aber keinen Zugang hat. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 5. November 2010 21:48 schrieb Garry garr...@gmx.de: Das übrigens glaube ich nicht. Du wirst m.E. keine Straße finden, die ein annähernd autobahnähnliches Verkehrsaufkommen hat, und die man (auch nicht nach Deiner Definition) als service bezeichnen kann. Freue mich schon, wenn Du doch ein Beispiel findest, aber ich bezweifle das sehr. Dann stell Dich z.B. mal in der Hochsaison morgens an die Parkplatzzufahrt zum Europpark. 4Millionen Besucher/Saison machen überschlagen (200Besuchstage,4Personnen/Fahrzeug) im Schnitt 5000PKW/Tag die aber grösstenteils morgens innerhalb 2h anfahren und abends im gleichen Zeitrahmen abfahren. Bei vielen grossen Messen ergibt sich ein ähnliches Bild, wenn auch an weniger Tagen. ja eben, 5000 am Tag, wahrscheinlich noch auf mehrere services verteilt (weil die Sammelstraßen vermutlich schon eher unclassified sein dürften), das kommt nicht an Autobahnen ran. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 5. November 2010 18:36 schrieb Peter Wendorff wendo...@uni-paderborn.de: und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich willkommen. Wer rendert denn Aufrisse aus OSM-Daten? Die Renderbeispiele sind IMHO sinnlos, ich würde Grundrisse vorschlagen. Mit derzeitigen Editoren ist sowas sehr schwer einzutragen. Ein Workflow wäre z.B. doppelte Wege zu zeichnen (wg. des Snappings) und diese dann mit unglue zu entkoppeln. Vertikale Verbindungen wirst Du nicht zeichnen wollen? M.E. kommt man damit auch an die Auflösungsgrenzen des derzeitigen Modells. Ich bin nach wie vor für externe Modelle, die verlinkt werden. Für den Weg unter dem Gebäude kann man in OSM covered verwenden. Durch die Linearität unserer Wege-Daten sind allerdings Fußgängerflächen grundsätzlich schlecht repräsentierbar. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 5. November 2010 22:24 schrieb Ulf Möller o...@ulfm.de: Am 05.11.2010 21:43, schrieb Wolfgang: Josm ist auf Netbooks nicht benutzbar. Doch, ich benutze JOSM seit zwei Jahren auf einem eeePC. Einziges Problem: einige Preset-Menüs sind nicht erreichbar - ungünstig bei Vorführungen für OSM-Einsteiger, aber beim normalen Editieren braucht man das nicht unbedingt. Auch ich benutze JOSM auf dem eeePC und auf einem anderen Laptop mit Ubuntu. Leider ist das Edit (oder tools?) -Menu nicht vollständig zugänglich, wenn man mehrere Plugins installiert hat (endet ausserhalb des Bildschirms und scrollt nicht). Mit den Preferences habe ich dagegen keine Probleme, die scrollen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 4. November 2010 22:26 schrieb qbert biker qbe...@gmx.de: Sobald die Bedeutung von width klar ist, könnte man enge Straßen in der Karte schmaler zeichnen. je nach Zoom. Die reale Breite hat naturgemäß in den meisten Zoomstufen nichts zu suchen, solange man daran interessiert ist, Straßen zu erkennen. Osmarender wertet width für Flüsse aus. das ist was ziemlich anderes und kartographisch üblich. Solange nicht klar ist, ob eine Straße im Gewerbegebiet mit 20m Gesamtbreite und 7m Fahrbahnbreite oder eine enge Altstadtstraße mit 7m Gesamtbreite und 4m Fahrbahnbreite das Tag width=7 erhält, kann man es nicht nutzen. ja, man sollte einfach mal ins Wiki schreiben, dass width die Fahrbahnbreite ohne Gehsteige enthalten sollte. das in den unteren Zoomstufen eine Alternative zu der heute gebäuchlichen Überhöhung der Breite. Gemeint ist die übliche nicht massstabsgerechte Darstellung der Breite, die je nach Zoomstufe deutlich breiter ist als in der Realität. ja, oder auch schmaler. In Z18 ist die OSM-Straße meist schmaler als die Realität. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 4. November 2010 22:14 schrieb Garry garr...@gmx.de: Am 04.11.2010 15:08, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 21:09 schrieb Carsten Moellercmindivid...@gmx.de: m.E. ist das semantischer Käse. Entweder ist ein Weg eine wichtige (allg.) Verbindung, dann kann er kein service sein, oder er ist eine Sackgasse, die nur zu einem bestimmten Ziel führt, und für alle anderen unwichtig ist, dann ist er ein service. Das ist m.E. gemeint mit service für Zufahrt. Ich verstehe nicht, warum man unbedingt service als Klasse vergeben muss für Wege, die ihrer Natur nach was komplett anderes sind als eine Parkplatzzufahrt oder Grundstücksauffahrt (weil es dahinter im Falle eines Fährhafens eben weitergeht). Man kann service auch als zweckgebundene Strasse betrachten die überwiegend (ich möchte nicht sagen ausschliesslich) eben einem speziellen Zweck dient, dabei aber durchaus auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. könnte man vielleicht (auch wenn ich dafür bisher keine Anhaltspunkte sehe), aber es würde die Lage m.E. nicht verbessern sondern deutlich verschlimmern und es würde nicht mehr klar sein, was man zu erwarten hat, wenn highway=service getaggt ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 4. November 2010 22:14 schrieb Garry garr...@gmx.de: Man kann service auch als zweckgebundene Strasse betrachten die... auch mal ein autobahnähnliches Verkehrsaufkommen haben kann. Das übrigens glaube ich nicht. Du wirst m.E. keine Straße finden, die ein annähernd autobahnähnliches Verkehrsaufkommen hat, und die man (auch nicht nach Deiner Definition) als service bezeichnen kann. Freue mich schon, wenn Du doch ein Beispiel findest, aber ich bezweifle das sehr. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 5. November 2010 10:20 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: hier kannst Du die Zahlen der Autobahnen finden: http://www.bast.de/cln_007/nn_39112/DE/Statistik/Verkehrsdaten/Downloads/zaehlung-2005-BAB-strassen,templateId=raw,property=publicationFile.pdf/zaehlung-2005-BAB-strassen.pdf ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 4. November 2010 23:09 schrieb tshrub my-email-confirmat...@online.de: was setzt Ihr für Fels? scree ist ja für loses Gestein. Da war vor einem Jahr Mal jemand/ein Thread aus Tschechien oder so ... da zumindest sind wir bei scree geblieben. das würde ich nicht tun. Du würdest auf Deutsch ja auch nicht Schotterfeld schreiben, wenn es nackter massiver Fels ist, oder? landuse=steppe landuse=savanna sind m.E. beides keine Landnutzungen eher landcover oder Landschaftsarten (landscape?). Darin können ja durchaus auch Landnutzungen vorkommen. ich finde ja, landcover deckt begrifflich natural und landuse ab, verschluckt es sozusagen(?), hm, landuse sollte man in jedem Fall deutlich trennen und landcover oder natural. Landuse ist die Bodennutzung, evtl. Landnutzung jedenfalls die Nutzung. Ich weiss, dass das derzeit nicht ganz klar ist (im groben allerdings ist es schon so umgesetzt). Weitere Tags würde ich schon danach trennen und evtl. landuse etwas aufräumen (sind nur wenige Tags, die nicht passen). steppe oder savanna würde ich bei Nutzungshinweisen als landuse (ggf. mit Nutzungsart, z.B. animal=goat) und sonst natural taggen (ggf. mit Pflanze). Hm, bin gerade mal auf diese Wikipediaseite gestoßen: http://de.wikipedia.org/wiki/Landnutzung die interessanterweise diesen Absatz enthält: Die 13 Hauptklassen, die für alle EU-Länder den Rahmen bilden, sind: * Siedlungsflächen (incl. Verkehrsflächen) * Ackerflächen * Dauerkulturen * Grünland * Laub- und Mischwald * Nadelwald * Alpine Matten * Latschen, Krummholz * Felsflächen * Spärliche Vegetation * Gletscher * Feuchtflächen * Wasserflächen. zunächst wird der Eindruck erweckt, die packten auch ungenutzte Flächen in landuse-Klassen, bei näherem Hinsehen wird allerdings klar, dass es sich hier um CORINE Landcover, also Bodenbedeckung handelt, genauso wie beim LLCS der FAO (Welternährungsorganisation). Zu letzteren habe ich übrigens zufälligerweise auch persönliche Kontakte, sollten wir da Fragen haben. An andere Stelle beschreibt der Artikel, dass Industrieländer üblicherweise zw. 20 und 50 verschiedenen Landuse-Differenzierungen anwenden. Weitere Landcover Klassifikationsbeispiele finden sich z.B. bei GLOBCOVER http://ionia1.esrin.esa.int/docs/GLOBCOVER_Product_Specification_v2.pdf ab Seite 20. Ich kann die Aversionen gegen Landcover als Tag nicht verstehen. Das ist am besten zu erkennen im Ggs. zu landuse, und meistens auch eindeutig. Der Begriff ist allgemein üblich in den Geowissenschaften. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beschriftung von Orten
Am 29. Juni 2009 16:56 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Bin ich denn der einzige, der Ordnung im Wiki haben möchte? wiki/cartographie/DE:... aber nicht alles irgendwieherum klatschen. wenn wir hier schon alte Threads aufwärmen, bitte lieber cartography, sonst wird es eher schlimmer als besser mit der guten Ordnung. ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 4. November 2010 22:26 schrieb Martin Simon grenzde...@gmail.com: Am 4. November 2010 20:21 schrieb Johannes Huesing johan...@huesing.name: ... wäre ich durchaus versucht gewesen, die Betonanker der Spannseile und die Seile selbst zu mappen. Wie aber würde man Seile mit statischem Zweck eintragen, etwa auch bei Hängebrücken? Line hat sich glaube ich nur als Wert zum Schlüssel power eingebürgert. ich sehe unsere Datenmodell als ziemlich ungeeignet an, auch vom Maßstab, diese Details einzutragen, insbesondere die Seile. Bei Widerlagern und Auflagern sehe ich das evtl. schon anders und ich würde es schon begrüßen, wenn man mehr abgestimmte Details für Brücken hätte. Das wären allerdings erst mal so Dinge wie den Gesamtumriss der Brücke, womit man auch bei getrennter Fahrbahn z.B. angeben könnte, dass es doch nur _eine_ Brücke ist, einen abstimmten Weg für den Brückennamen, insb. sofern die Straße darüber einen anderen trägt, sowie einen Konstruktionstyp und ggf. Tags für Details wie Auflager (explizit und implizit also als Mengenangabe, könnte man alternativ auch mit Feldern angeben (i.d.R. eins weniger)) und Konstruktionstyp (z.B. Hängebrücke, Balkenbrücke, Bogenbrücke, Fachwerkbrücke etc. vermutlich mit Subtags, also bitte nicht als Haupttag sowas wie vorgespannte Stahlbetonplattenbalkenbrücke einführen). Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für deine Seile wohl building=yes. :-p building=rope wäre das analog. Im Bsp. Sony Center war das mit building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht unbedeutend. Im Ernst: ich denke um die Problematik der information dies ist *ein* Gebäude zu umgehen, die es auch immer gibt, wenn Mapper z.B. unterschiedlich hohe Gebäudeteile als separate (wenn auch verbundene) Polygone mit building=yes taggen, wäre es angebracht, Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal buildingpart=*. ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff trennen, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 5. November 2010 06:27 schrieb Johannes Huesing johan...@huesing.name: Wie man es auch nennt, für die Seile würde ich es nicht verwenden, da ich den Gebäudeteil nur für Knoten und geschlossene Wege definieren, Seile aber als offene Wege modellieren würde. Kannst Du das mal ausführen, wie Du Dir das in einem 2,5-D-Modell (abgesehen von den genauen Key/Values) vorstellst? Wenn man ein Linienmodell machen wollte, sollten die Stützen 2 verbundene Nodes jeweils übereinander haben, also einen vertikalen Way (da schonmal viel Spaß mit den gegenwärtigen Tools), so dass man an den oberen Node (hier der 2. Spaß) ein Seil anschließen kann. Alternativvorschlag: Umriss einzeichnen und ein externes 3D-Modell damit verlinken. Format müsste man klären, anbieten würde sich Blender (opensource), dxf / 3ds (weit verbreitet) es gibt aber natürlich noch Myaden anderer 3D-Formate (shape, stl, etc.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Am 5. November 2010 07:25 schrieb Kay Drangmeister k...@drangmeister.net: Am 03.11.2010, 20:51 Uhr, schrieb ant antof...@gmail.com: gut, aber ein echter Graustufen-Style müsste schon mehr sein als eine Graustufenkonvertierung des Originals: Es braucht stärkere Kontraste, [...] für Menschen, die keinen Farbdrucker besitzen, als auch für Farbenblinde. sehe ich auch so. Deinen Wunsch sehe ich ein, jedoch war dies nicht Zweck des Base-Layers. Dieser war es, gerade kontrastarm zu sein, d.h. die in darüber liegenden Layern besser herauszustellen. ich finde den extra Stil eine gute Übung, aber schneller wäre es vermutlich gegangen, einfach mit einer Bildbearbeitung per batch aus den bunten Tiles die Farbe rauszunehmen (desaturate o.Ä.). Eine Karte nach deinem Wunsch ist bestimmt möglich, aber nur schwer automatisch hinzubekommen. Dazu bräuchte es mehr Wissen um die (verschiedenen möglichen) Farbschwächen. es geht ja nicht primär um Farbschwächen, das ist schon richtig, aber in jedem Fall ist doch sinnvoll, die dargestellten Features auch unterscheiden zu können. So wie es jetzt ist, ist es jedenfalls Zufall, da manche Farben jetzt ähnlich aussehen, andere nicht, ohne dass das irgendjemand gewollt hätte, es ist einfach so. Wenn einen die Features nicht interessieren, oder nur grob (also z.B. alle Landuses gleich, oder Gruppen davon bilden), dann müsste man in jedem Fall manuell vorgehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Am 4. November 2010 23:12 schrieb Peter Herison pheri...@web.de: Hat jemand eine Idee wie ich das am sinnvollsten mache? AFAIK kann GPS-Babel die Tracks vereinfachen, indem es die Anzahl der Punkte in Abhängigkeit von einem gegebenen Toleranz-Abstand reduziert. Damit könntest Du evtl. den Gesamttrack so reduzieren, dass er die maximale Punktanzahl einhält. Wie Du die Tracks zusammensetzen kannst (ob z.B. GPS-Babel das auch kann), weiss ich nicht, notfalls kannst Du das ja auch manuell mit jedem Texteditor machen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für gesprengte Häuser?
Wird allerdings als normales Gebäude gerendered. Würde mich nicht wundern wenn Mapnik sogar building=no rendered. Was bei 0,003% Anteil allerdings kaum auffällt. ;-) Das war mal so, ist aber gefixt: (select way,building,leisure,railway,amenity,aeroway from prefix;_polygon where (building is not null and building != 'no') Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Am 5. November 2010 12:19 schrieb Georg Feddern ne...@bavarianmallet.de: ich habe es jetzt nochmals mehrfach überschlafen - und eben die deutsche Seite mit Erläuterungen an das englische Original angepasst. Ich habe das jetzt nochmal komplett umgestellt, weil einfach zu viele Fehler drin waren. Zunächst mal hat das mit Torfgruben nichts zu tun. Torf ist nicht mineralisch sondern organisch. Evtl. sind auch Kiesgruben damit nicht zu taggen, da bin ich mir allerdings nicht sicher (Schotter gehört dazu). Man sollte nochmal auf der englischen Liste nachfragen (habe ich gemacht). Die Diskussion hier betraf den Abbau von mineralischen Stoffen in allen Korngrößen, also von Stein über Schotter, Sand zu Ton. Ob Ton wirklich noch inbegriffen ist, weiss ich nicht genau, Schluff dito. Auch ist die Übersetzung von quarry nicht Tagebau. Tagebau ist eines der Kriterien (neben mineralisch), und heisst im englischen open cast. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 5. November 2010 13:32 schrieb Fabian sh...@nurfuerspam.de: Das erinnert etwas an die site relation wo parkplaetze zu einkaufscentren gehoeren. Ich bin gegen site für Gebäudeteile. Mehrere Gebäudeteile= ein Gebäude, (potentiell) mehrere Gebäude = eine site. Was man m.E. eher machen könnte wäre einen neuen Typ Relation, der systematisch gruppiert, z.B.: type=group group_type=site / building / river / legal_entity / ... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 5. November 2010 13:49 schrieb tshrub my-email-confirmat...@online.de: ich finde ja, landcover deckt begrifflich natural und landuse ab, verschluckt es sozusagen(?), hm, landuse sollte man in jedem Fall deutlich trennen und landcover oder natural. Landuse ist die Bodennutzung, evtl. Landnutzung jedenfalls die Nutzung. Boden-, Naturnutzung ... ja, aber Nutzung. Ebenso natural strukturieren! natural ist eine bunte Mischung, da sind auch Bäume, Höhleneingänge (übrigens eines der ältesten natural tags von 2007), Strände, Gipfel (2007), Buchten, Klippen (Juni 2006), Küstenlinien, einzelne Steine (block), Quellen (2007) drin. Alles kein landcover. Es stimmt einfach nicht, dass landcover in OSM natural und landuse ist. Es ist alles unstrukturiert in dem Bereich. Hm, bin gerade mal auf diese Wikipediaseite gestoßen: http://de.wikipedia.org/wiki/Landnutzung interessant geht so, ist z.T. ziemlich unfundiert zusammengewürfelt, so ähnlich wie unser Wiki ;-), m.E. deutlich unter dem Standard des durchschnittl. Wikipedia-Artikels. ja, das ist der Landcover-/ Maschinen-Ansatz () der z.B. nicht zwischen natürlich und genutzt unterscheiden kann. Der dürfte genau genommen auch nicht mit Landnutzung übertitelt sein (z.B. zu Felsfläche). Das ist - spez. in solch einem großen OSM-Rahmen - fehlerträchtig. ja, ich habe da schon ein paar Hinweise ergänzt, müssen aber wohl erst noch geprüft (und abgelehnt?) werden... Landcover (CLC) gibt es länger als OSM (?) und den Begriff hätte man gleich am Anfang einführen können. Aber man hat einen Unterschied zwischen natural und landuse gewählt und das ist m.E. auch nicht verkehrt und - reichhaltiger. man hat da nichts gewählt, irgendjemand hat mal ein paar der natürlichen Bodenbedeckungen in natural einsortiert, aber soweit ich das recherchiert habe nicht am Anfang des natural tags sondern später. Hier wäre der Begriff natural zu diskutieren: ... natürliche Elemente, wie z.B. Landschaften oder geologische Gegebenheiten, und geographische Punkte wie Bucht, Klippe, Gipfel, ... ... An andere Stelle beschreibt der Artikel, dass Industrieländer üblicherweise zw. 20 und 50 verschiedenen Landuse-Differenzierungen anwenden. das ist schön. Dann Mal los, suchen ... :) wozu? Wir machen das besser ;-). Klar, man kann sich mal ansehen, was die so haben, aber komplett wegwerfen wird man unser Schema ja kaum, und wenn man nur alle Unterarten der orchards zusammenzählt kommt man vermutlich schon auf über 50 ;-) landcover deckt doch die Begriffe landuse natural ab - bzw. umgekehrt(?!?). nein, m.E. nicht. Ein paar Tags sind in natural drin, noch weniger in landuse. Das ist nicht enthalten sondern großteils orthogonal, insb. zu landuse. landcover bringt OSM und die user auf ein Maschinenniveau, ist ein Verlust an Genauigkeit/Info/Wertigkeit. es soll ja zusätzlich getaggt werden, nicht stattdessen. Wofür (bloß) sollte ich landcover nehmen? für eine Ansammlung von Bäumen, die kein Wald ist? Für sand am Strand? Für Fels am Strand? Für Wälder wo keine Bäume wachsen (landuse=forest, landcover=scrubs), für Grassflächen, die keine Wiesen sind, für Wüsten (natural=desert), um die Bodenbedeckung zu klären, etc. Für Micromapping in der Stadt ist es natürlich auch geeignet. Es tauchen immer wieder solche Fälle auf. z.T. geht es mir auch um ein semantisches Geraderücken und um Klarheit für kommende Werte. Wir haben bisher rein Europa zentrierte Tags für Bodenfeatures. Schon jetzt ist es teilweise chaotisch. landuse sollte m.E. die Bodennutzung beschreiben, landcover die Bodenbedeckung, und natural bleibt für die geografischen features. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was passiert bei splitten oder ändern ei nes node/way/relation mit der ID?
2010/11/4 Tom Müller tomsmuel...@gmx.net: Ja ich weiß ja, dass das Beispiel destruktiv ist. Ich möchte eigentlich nur wissen wie konsistent z.B. Abbiegebeziehungen sind. Kann es sein, dass die bei ändern eines Ways kaputt gehen, wenn der Mapper unaufmerksam ist, oder wird davor so gewarnt, dass es ausversehen nicht passieren kann. Oder verhindert es gar die API. Die API verhindert praktisch gar nichts, jedenfalls nicht auf dieser Ebene, JOSM kommt mittlerweile mit Relationen ganz gut zurecht (bei einer route oder mp werden nach Splitten beide Teile zur Aufnahme in die relation vorgeschlagen. Es kann aber trotzdem, wenn man z.B. nur den Way lädt, und nicht die passende Relation dazu, vorkommen, dass auch JOSM (weil er von der relation nichts weiss) eine Relation zerstört. Allerdings nicht, wenn man über herunterladen einer BB vorgeht, nur wenn man die ID direkt eingibt und herunterlädt. Bei den anderen Editoren weiss ich es nicht, potlatch 1 wird AFAIK nicht mehr intensiv entwickelt, weil man sich auf PL2 konzentriert, daher vermute ich mal, dass es dort mit Relationen nach wie vor Probleme gibt. Merkaartor weiss ich nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für Wüstengebiete
Am 3. November 2010 23:23 schrieb tshrub my-email-confirmat...@online.de: gibt es schon tags für Landschaften in der Wüste (z. B. Sahara). eher nicht M.E. könnte ein Dünenbegriff eingeführt werden natural=dune ggf. noch unterscheiden natural=inlanddune oder natural=seadune ich würde unterscheiden in landcover (und ggf. landuse). Natural entspricht teilweise landcover. Bei Sanddünen wäre z.B. landcover=sand möglich und zusätzlich könnte man natural=dune für die Dünen setzen. und für Stein-Geröll-Gebiete (Hamada) nur natural=stone gefunden. für (Geröll), Schuttflächen, ggf. Blockhalden natural=scree +1 was setzt Ihr für Fels? scree ist ja für loses Gestein. und als Zusatztag das Material: surface=sand surface=lava ich bin dagegen, surface dafür zu verwenden, weil surface nur die Oberfläche beschreibt. M.E. sobald es über die reine Oberfläche hinausgeht wäre ein landcover tag angebracht. Material-Key gibt es glaube ich nicht(?) könnte man aber einführen, braucht man allerorten. landuse=steppe landuse=savanna sind m.E. beides keine Landnutzungen eher landcover oder Landschaftsarten (landscape?). Darin können ja durchaus auch Landnutzungen vorkommen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für Dünen
Am 3. November 2010 23:45 schrieb Claudius claudiu...@gmx.de: Am 03.11.2010 23:23, tshrub: Für Dünen (Erg) habe ich in den Map Features nur natural=sand und =beach ... :) M.E. könnte ein Dünenbegriff eingeführt werden natural=dune ggf. noch unterscheiden natural=inlanddune oder natural=seadune Dünen selbst würde ich nicht versuchen zu taggen, da sie häufig nicht all zu stationär sind. Dünengebiete mit natural=dune zu bezeichnen finde ich nicht unbedingt daneben, problematisch sehe ich nur die große Überschneidung mit natural=sand - Eine Lösung habe ich aber nicht parat. Die Abgrenzung ist wohl einfach etwas unscharf. Klar, Dünen bewegen sich, aber z.B. in Arcachon (größte Wanderdüne Europas, zumindest nach Eigenwerbung) hält sie sich schon ziemlich lange. Evtl. müsste man die Dünen alle paar Jahre mal etwas verschieben, aber sie gar nicht zu mappen halte ich nicht für sinnvoll. (Klar, wenn man alle Dünen der Sahara mappen wollte, hätte man ne Weile zu tun). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DFS verwendet OSM für Overlay mit Flugbe wegungen
Am 4. November 2010 08:32 schrieb Christian Slotwinsky slo...@web.de: Hallo miteinander, für den, den es interessiert, der DFS verwendet in seiner Anwendung Stanly_Track OSM-Karten zur Darstellung von Flugbewegungen in Flughäfennähe. super, dass die jetzt OSM verwenden, wäre nett, wenn sie auch darauf hinweisen würden, dass man die Karten daher im Rahmen von cc-by-sa kopieren darf, und dass man OSM auf die Kartenbilder schreiben sollte, so wie es die Lizenz will. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 4. November 2010 03:16 schrieb Stephan Wolff s.wo...@web.de: Am 31.10.2010 09:19, schrieb Jochen Topf: On Sat, Oct 30, 2010 at 10:49:31PM +0200, Stephan Wolff wrote: Umdeutung schützen will (z.B. Verwendung von natural=beach für Sandbunker auf dem Golfplatz) Also das mit dem Sandbunker auf dem Golfplatz, der als natural=beach getagged ist, lassen wir mal weg. Das ist kein echtes Problem. Die paar Stellen, wo es das auf der Welt gibt, sind ein Witz. Ja, das kein wirklich bedeutendes Problem. Solange das Tag nur zum Erstellen von Karten benutzt wird, ist es irrelevant. ich kann Euch beiden da nicht folgen. Wieso sollte das kein Problem sein, wenn ein Sandbunker auf dem Golfplatz als Strand eingetragen wird? Wenn ich eine Karte erstelle, wo ich Strand auf Flächen schreibe (mind. in der Legende wird das ja auftauchen), die eigentlich Sandbunker sind, habe ich doch ein Problem, obwohl ich nur Karten erstellt habe. Es gibt deutlich mehr Golfplätze (und wenn man dann auch noch die Sprunggruben von Leichtathletikflächen, Beachvolleyballfelder, und sonstige Sandflächen so taggt...) als Ihr denkt ;-) Ausserdem gibt es ein Proposal von März 2008, wo das alles schön aufgelistet wird: http://wiki.openstreetmap.org/wiki/Proposed_features/Golf_course M.E. sollte man weder im Kleinen noch im Großen für die Renderer taggen, und das nicht als Witz abtun. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] How did you contribute to OpenStreetMap ?
Ich hoffe, ich poste hier nichts altbekanntes. Pascal Neis hat eine nette Fun-App ins Netz gestellt: http://hdyc.neis-one.org/ Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 4. November 2010 20:39 schrieb Garry garr...@gmx.de: Verkehrsflughafen handelt. Ich will die Segelflieger ja nicht unterschlagen, aber für die Bedeutung eines Fluggeländes ist eher das größte starten/landen könnende Verkehrsmittel entscheidend, als das kleinste. Nimm Dir den Blackforest-Airport in Lahr, dort können die grössten Flugzeuge der Welt landen, verkehrstechnisch hat er aber nur eine geringe Bedeutung hast Du das eher gesehen? Ist natürlich nicht das einzige Kriterium. Sieht im Gegenteil so aus, als könnte man die Bedeutung durchaus einschätzen, zumindest traust Du Dir das für Lahr zu. Man kann ja mal anfangen, und dann je iterativ und im Vergleich mit anderen Flughäfen diese erste Einschätzung auch nochmal anpassen. Vermutlich hätten wir in kürzer Zeit ein ausgewogenes System. Einfach alles vom Modellfluggelände bis zum Großflughafen gleich zu taggen finde ich nach wie vor die schlechtere Lösung. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 4. November 2010 20:39 schrieb Garry garr...@gmx.de: Davon abgesehen waren die Freunde der Flughäfen in OSM schon sehr früh sehr fleissig und haben die Landebahnen schon vor Jahren vielfach auch mit Rollwegen eingetragen so dass es diesbezüglich kaum noch etwas zu mappen gibt. Kannst ja mal hier nachsehen, wie die Hierarchie ist, und mir danach nochmal bestätigen, dass wir die Flughäfen optimal taggen: http://www.openstreetmap.org/?lat=41.659lon=-88.771zoom=10layers=M Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fluggelände was: AIO - Routing üb er Fähren
Am 4. November 2010 20:38 schrieb Garry garr...@gmx.de: Wenn Du jetzt mal den Modellflug aussen vor lässt - was erwartest Du vom Haupttag eines Flugplatzes herauslesen zu können? ich würde mehrere Klassen (4 und eine weitere für die Modellflieger) machen, die hierarchisch zu sehen sind. Bedeutendere oder größere Flughäfen hätten eine höhere Klasse. Das könnte z.B. durchaus sowas sein wie Anzahl der Starts/Landungen, Anzahl der Airlines, Anzahl der Passagiere, Anzahl und Ausbau/Länge der Start/Landebahnen. Das macht einerseits als einzelne Tags Sinn, könnte aber auch vom Mapper schonmal ein eine der Hauptklassen (von aeroway) sortiert werden. Am höchsten wäre sowas wie internationaler Großflughafen (die Kriterien sollten international abgestimmt werden). Dann ein normaler Flughafen (was das ist hängt sicher auch vom Land ab, der Standard sollte z.B. innerhalb der EU oder innerhalb der USA in etwa korrespondieren). und dann alles was es an kleineren Flugplätzen gibt wo auch mehrsitzige Personenflugzeuge starten/landen. Dann noch Startplätze von Drachenfliegern, Ultraleichtflugzeugen, Segelfliegern, ganz kleinen Flugzeugen... All die anderen Informationen wie Landebahnen etc. würde man idealerweise natürlich trotzdem taggen. Wer sich nur darauf verlassen will, kann ja die anderen ignorieren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 08:21 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: deshalb sind wir beim letzten Mal schon nicht weitergekommen... Irgendein Wohnzimmer Extremist findet sich halt immer, der die Diskussion hier in die Ergebnislosigkeit führt. Diesmal bist es halt nicht du ;-) Beispiele? Ich gebe zu, dass ich einer der Vielschreiber auf der ML bin, aber ich sehe mich eigentlich nicht als Wohnzimmer Extremist, ich bin durchaus draußen zum mappen, und meine Beiträge hier sind m.E. ergebnisorientiert und entstehen nicht mit dem Ziel der puren Diskussion. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 3. November 2010 09:05 schrieb Johann H. Addicks addi...@gmx.net: Am 03.11.2010 08:13, schrieb Peter Wendorff: Ich sehe in diesem Fall das Problem nicht. Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen. Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal begegnet) ist es einfach etwas detaillierter gemappt; Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige Sonnensegel hängen. siehe z.B. http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität hat das wenig zu tun. Sehe ich anders. Die Realität wird m.E. ziemlich gut wiedergegeben, daher der hohe Wiedererkennungseffekt. Mit Building=roof ist das eine brauchbare Beschreibung. Klar, es ist eine eher großmaßstäbliche (kl. Zoom) Abstraktion, der räumliche Fachwerkträger wurde z.B. nicht in allen Details wiedergegeben ;-). Wenn man das weglassen würde, wäre m.E. die Darstellung schlechter, d.h. weniger gut zu erkennen und dem realen Raum weniger angemessen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 3. November 2010 02:02 schrieb Walter Nordmann walter.nordm...@web.de: wenn das doch nur soo einfach wäre. aber HIER steht die realität: http://de.wikipedia.org/wiki/Postleitzahl_%28Deutschland%29#Postleitzahlenarten Zitat: Die Postleitzahlen lassen sich in verschiedene Kategorien einteilen. Die häufigste Art ist die Hauszustellungspostleitzahl, gefolgt von der Postfachpostleitzahl. Großempfänger erhalten von der Post entweder eine eigene Postleitzahl oder teilen sich diese mit weiteren Großempfängern. also vier möglichkeiten und nicht nur zwei. p.s. ich habs auch erst nicht glauben wollen. das ist soweit ja alles längst klar. Die Frage war, wie bzw. was wir davon in OSM übernehmen. Im addr:postcode (oder wie das heisst, nehme bei addr immer ein preset) sollte m.E. grundsätzlich die Hauszustellungs-PLZ eingetragen werden. Für Postfachpostleitzahl und Großkunden- bzw. Großkundensammelplz reicht m.E. ein weiterer key aus. Kann man sowieso nicht so ohne weiteres erkennen, was es ist, und mehrere davon wird ein Adressat nicht haben, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Justizminister wollen Auflagen für Geoda tendienste
Am 3. November 2010 09:47 schrieb Philip Gillißen gue...@freenet.de: Die Justizminister von Bund und Ländern fordern von der Bundesregierung, Geodatendienste wie Google Street View möglichst rasch mit einem speziellen Datenschutzgesetz in die Schranken zu weisen. http://www.heise.de/newsticker/meldung/Justizminister-wollen-Auflagen-fuer-Geodatendienste-1129627.html Das bedeutet anscheinend neuen Ärger auch für OpenStreetMap. Genaueres ist noch nicht bekannt. Meine Meinung dazu: Lobbyismus starten, auch und gerade für OpenStreetMap! Klage vor dem Bunderverfassungsgericht, der öffentliche Raum muss öffentlich bleiben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:04 schrieb Wolfgang wolfg...@ivkasogis.de: In dieser Reihenfolge. Ich bin ein paar Jahre dabei, aber wenn ihr nicht sauber definieren könnt, was eigentlich getaggt werden soll, werde ich mich um Bushaltestellen überhaupt nicht mehr kümmern. Wenn Du ein paar Jahre dabei bist, dann schreibe nicht ihr, sondern wir ;-) M.E. gibt es einen Konsens, highway=bus_stop neben den Weg an die Stelle des Mastes zu setzen. Für die Redundanzen die Oxomoa vorschlägt (bus=yes etc.) gibt es m.E. keinen Konsens und auch keine Erfordernis. Wegen mir könnte man das aber auch alles vereinheitlichen, sofern das an allen (den meisten) Stellen wie Editoren, Wiki und Daten geschieht, und es dafür international einen Konsens gibt. (d.h. ich hänge nicht unbedingt daran, Bushaltestellen im Highway-namespace zu führen, aber wenn eine Hälfte es so macht, und die andere anders, finde ich das schlechter). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:13 schrieb Claudius claudiu...@gmx.de: Genau um in diese Ambivalenz Sinn reinzubringen tagge ich nach ÖPNV-Schema mit public_transport=stop_position auf dem weg und public_transport=platform an der Warteposition. Die stop_position erhält zusätzlich oft noch den highway=bus_stop. damit bist Du einer derjenigen, die highway=bus_stop auf den Weg setzen, wogegen seit längerem die Wiki-Definition steht, und was auch hier AFAIK die Mindermeinung darstellt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Sortierung der Eigenschaften
Am 3. November 2010 10:38 schrieb Chris66 chris66...@gmx.de: Kann man in JOSM die Reihenfolge der Eigenschaften beeinflussen? In Holland zB. stehen die AND Sachen (Import_level etc.) ganz oben, so dass man zu den wichtigen Tags (highway, etc.) immer runterscrollen muss. AFAIK ist das alphabetisch, wenn Du das Fenster ausklinkst kannst Du es auch bei kleinen Bildschirmen vertikal groß genug stellen, dann erübrigt sich das Problem bei unter 20-30 Tags an einem Objekt eigentlich ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:31 schrieb Claudius claudiu...@gmx.de: Am 03.11.2010 12:18, M∡rtin Koppenhoefer: Am 3. November 2010 12:13 schrieb Claudiusclaudiu...@gmx.de: Genau um in diese Ambivalenz Sinn reinzubringen tagge ich nach ÖPNV-Schema mit public_transport=stop_position auf dem weg und public_transport=platform an der Warteposition. Die stop_position erhält zusätzlich oft noch den highway=bus_stop. damit bist Du einer derjenigen, die highway=bus_stop auf den Weg setzen, wogegen seit längerem die Wiki-Definition steht, und was auch hier AFAIK die Mindermeinung darstellt. Ich halte mich da an den Zusatz zur Empfehlung neben dem Way zu Taggen. Zitat: however this has been the subject of some debate, because it has the disadvantage of not explicitly associating the bus stop with the way (a headache for routing software) [1] und das in meinen Augen sinnige unified_stoparea proposal [2]. kann Dir das nicht völlig egal sein, wo Du die stop_position sowieso nochmal extra einträgst? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Am 3. November 2010 13:20 schrieb olvagor o...@terbrueggen.net: Am 03.11.2010 13:14, schrieb Carsten Schönert: wie würdet Ihr eine Tongrube taggen? Dazu kann ich bisher nichts vergleichbares finden. landuse=clay_pit ? Ist eine Tongrube nicht einfach ein Sonderfall eines Steinbruchs? nein, ein Steinbruch ist es definitiv nicht, das gilt nur für die Förderung von Festgestein , Tagebau gilt hingegen schon, Bergbau passt auch. ___Das engl. Wort quarry passt ;-) ___ Mal wieder ein gutes Beispiel, dass man beim Übersetzen von Tags höllisch aufpassen muss, bzw. de:Wort=en:Wort nicht funktioniert. Es kommt jeweils auf die genaue Bedeutung an. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tongrube taggen
Am 3. November 2010 14:37 schrieb Georg Feddern ne...@bavarianmallet.de: es scheint so, als sollte landuse=quarry mit resource=* allgemein für die oberflächliche Resourcenentnahme verwendet werden. Halte ich durchaus für sinnvoll - bin aber nicht so bewandern, was ein Muttersprachler dazu sagen würde - schon mal auf Tagging gesucht? Aber vielleicht wollte das auch nur jemand ... Wikipedia:en sagt dazu: Open-pit mines that produce building materials and dimension stone are commonly referred to as quarries. People are unlikely to make a distinction between an open-pit mine and other types of open-cast mines,[citation needed] such as quarries, borrows, placers, and strip mines. das kommt aus dem Tagebau-Artikel: http://en.wikipedia.org/wiki/Open-pit_mining Es scheint also durchaus im engl. auch eine Reihe von differenzierenden Fachwörtern zu geben. Wie immer kommt es da auch auf die Perspektive an, z.B. passen sowohl http://en.wikipedia.org/wiki/Borrow_pit als auch clay_pit . Letzteres ist spezifischer, ersteres bezieht sich nicht auf das Material an sich, wohl aber auf die Verwendung an anderer Stelle. Hier gibts auch noch mal ne Menge Differenzierungen: http://en.wikipedia.org/wiki/Surface_mining Das Problem ist, wenn Du auf tagging fragst, bekommst Du oft auch eine Wald-und-Wiesen-Antwort, die bei weiterer Recherche oft nicht trägt, genauso wie Du auch auf Deutsch nicht erwarten kannst, dass Du fachlich korrekte Antworten zu Spezialthemen von jedermann bekommen kannst. Bevor jetzt der allgemeine Aufschrei kommt, das könnten die Mapper sowieso hinterher nicht auseinanderhalten, und man solle es nicht zu kompliziert machen: m.E. geht das durchaus, man (jemand, der das Fachwissen hat, ich bin das bei diesem Thema auch nicht) müsste nur detailliert beschreiben, wie sich die einzelnen Arten voneinander abgrenzen, und schon kann in fast allen Fällen auch der Laie den richtigen Tag vergeben. Eins der Probleme bei OSM ist gelegentlich, dass als Haupttag erstmal ein spezifischer Spezialfall eingeführt wird (z.B. village_green, arts_centre, etc.), und dann alles ähnliche auch damit versehen wird, weil es am ehesten passt. Ob das bei quarry auch der Fall ist, kann ich nicht beurteilen, aber es wäre m.E. nicht schlecht, wenn der Haupttag (landuse) was möglichst allgemeines bedeuten würde (Abbau von Mineralien), wo man Sandgrube, Kiesgrube, Tongrube (die sich jeweils nur in der Korngröße des abgebauten Materials unterscheiden) genauso wie Steinbrüche alles in einen Topf schmeissen kann, und die Details dann mit Subtags geklärt werden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 14:22 schrieb Garry garr...@gmx.de: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: Flugplatz zu finden. Für die Darstellung eines Fluggeländes auf einer Karte ist das aber erstmal unerheblich. Da sind die Kernaussagen erstmal: Achtung Fluggelände! Lebensgefahr - unbefugtes Betreten... deshalb sind wir beim letzten Mal schon nicht weitergekommen... Es hat sich schon beim letzten mal gezeigt dass es keinen Sinn macht irgendwelche künstlichen Einteilungen für etwas zu machen das fliessende Übergänge hat. Quatsch, fliessende Übergänge gibt es praktisch überall, ob das jetzt bei Flüssen (SCNR, hier im vgl. zu Bächen), Dörfern/Städten, oder Straßenkategorien ist. Das ist kein Grund, bei Flughäfen so was nciht zu machen. Es gibt ja z.B. auch sprachlich die div. Unterscheidungen wie Flughafen, Flugplatz, etc., die da ein Beispiel sind. Einfach dazutaggen was tatsächlich vorhanden ist beschreibt die Situation am besten. das ist immer gut, hier lenkt dieses Argument m.E. allerdings nur davon ab, dass man zusätzlich auch eine Hierarchie der Gesamtanlage Flughafen/platz haben könnte. Könnte z.B. auch eine site-relation sein, die einem da etwas bei der Auswertung hilft. Luftverkehrsseitig die Angaben über die Landebahn und flugsicherungstechnischen Einrichtungen, Passagierseitig Angaben wie Linienflüge, Charterflüge, Taxi-Flüge, Rundflüge,... jaja, ist ja alles gut und richtig. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 14:21 schrieb Garry garr...@gmx.de: Am 03.11.2010 00:44, schrieb M∡rtin Koppenhoefer: Modellflug-gelände / -startplatz habe ich auch noch nie mit einem regulären Flugplatz zusammen gesehen. Es werden Beispiele dafür gab es in der letzten Diskussion. Durch entsprechende zeitliche Regelungen ist das möglich. OK, es ist alles möglich, aber nur weil nachts (oder sonst wann) Modellflieger ein Fluggelände nutzen können, heisst das ja nicht, dass sich an der grundsätzlichen Einstufung etwas ändert. Genauso wie auch die Tatsache, dass es auf dem Friedrichshafener Verkehrsflughafen auch Segelflugzeuge gibt nichts daran ändert, dass es sich um einen Verkehrsflughafen handelt. Ich will die Segelflieger ja nicht unterschlagen, aber für die Bedeutung eines Fluggeländes ist eher das größte starten/landen könnende Verkehrsmittel entscheidend, als das kleinste. Es wird doch sonst in OSM immer ganz gross geschrieben dass zu taggen was vorhanden ist, wo ist jetzt hier das Problem? Sämtliche Eigenschaften der Landebahn beschreiben und gut ist. damit muss es eben noch nicht gut sein. Man könnte auch ein Taggingschema haben, wo man nichtmal eine Landebahn zu mappen braucht, um schonmal ne grobe Ahnung davon zu vermitteln, um welche Art Flughafen es sich handelt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 14:36 schrieb Carsten Moeller cmindivid...@gmx.de: Meinst du damit, hier eine Relation anzulegen oder einen zweiten Weg? Falls Relation, dann bitte bedenken, dass diese von Routern kaum betrachtet werden, weil viel zu aufwändig und teilweise kaum beherrschbar. (Speicher, Laufzeitverhalten, etc...) das ist einzig vom Router und dessen preprocessing abhängig, der routet ja sowieso nicht auf OSM-Daten, ohne die vorher fürs Routing schonmal zu bearbeiten. Tags interpretiert werden. Und ganz wichtig: Hier sollten die Tags innerhalb der Ways ausreichen und nicht erst hintenrum über Relationen besorgt werden. Wenn Du damit meinst, dass man auf die Gleise taggen soll, ob da ein Autozug fährt: m.E. eher nicht. Das ist klar eine Eigenschaft der route, nicht der Gleise. Autozüge können auf allen Gleisen (naja) fahren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 15:08 schrieb Peter Wendorff wendo...@uni-paderborn.de: Ich stelle mir die hier vorgeschlagenen Routen eher so vor, dass sie als abkürzende Wegstücke eingebaut werden können. Eine Relation vom Typ ferry|car_train, die zwei nodes mit role=entrypoint (völlig willkürlich und nicht über die Formulierung nachgedacht) enthält, lässt sich im RoutingGraph als Weg von entrypoint1 nach entrypoint2 und Gewicht n betrachten. Abfragen kann man diese Routen recht einfach: Relationen mit type=ferry|car_train abzufragen ist nicht schwieriger als highways mit type=secondary. sehe ich auch so. Man könnte auch noch die Fahrtzeit (en) angeben mit einem Tag in der Route. Die Alternative ist, für den Router falsch zu taggen (aber wenn ich Fähren benutzen will, ist die Verkehrsbedeutung doch viel höher vs. das ist'n Parkplatz mit 'ner Warteschlange, die Zufahrt ist kaum ausgebaut) ein Parkplatz ist es m.E. nicht, eher ein Wartebereich. Und dem eine niedrige Verkehrsbedeutung zuzumessen ist relativ (wenn man die Fähre benutzen will, ist die Bedeutung enorm, andererseits ist vermutlich nicht allzu viel Verkehr dort verglichen mit einer Autobahn, andererseits sicher mehr als auf einer unclassified im ländlichen Raum. Klar, jeder Supermarkparkplatz hat auch eine hohe Frequenz an Fahrzeugen --- nur dass die dort in eine Sackgasse einfahren, es ist dort im Ggs. zum Fährterminal keine Durchgangsstation sondern ein hin und zurück, d.h. Bedeutung für den Durchgangsverkehr gleich null, daher service.). Der Ausbauzustand hat mehr mit den möglichen Geschwindigkeiten als mit der Verkehrsbedeutung zu tun (bzw. würde ich hier argumentieren: da man sowieso nicht schneller als Schrittgeschwindigkeit (oder 20 oder was auch immer) fahren darf, braucht das auch nicht autobahnähnlich ausgebaut zu werden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fluggelände was: AIO - Routing üb er Fähren
Am 3. November 2010 17:40 schrieb Garry garr...@gmx.de: Am 03.11.2010 01:20, schrieb M∡rtin Koppenhoefer: Mit Deinem Standpunkt aus der Tongrube stimme ich doch überein: Von daher verstehe ich nicht warum Du es hier anderst gelöst haben willst? will ich ja gar nicht. Die Kunst ist so spezifisch wie nötig aber so generisch wie möglich zu taggen. Wenn Modellflugplätze und Großflughäfen denselben Haupttag erhalten, vermischt man m.E. 2 völlig unterschiedliche Dinge miteinander (Personbeförderung und Freizeitspaß) und das kann niemandem dienen. Das wäre noch nichtmal so, wenn Autobahnen und Feldwege erstmal denselben Tag erhielten, und man dann an den Abständen der Seitenpfosten und Vorhandensein von Leitplanken ableiten sollte, was was ist, sondern sogar noch eine Stufe härter. Klar, es gibt Gemeinsamkeiten (Starten und Landen von Fluggeräten, potentielle Gefährdung, etc.), aber die Unterschiede sind --- zumindest in meinen Augen --- deutlich größer. Ich würde Tongruben und Kiesgruben, auch Steinbrüche erstmal in eine Kategorie packen, aber Misthäufen würde ich da z.B. nicht reintun. Oder Bodenverfüllungen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Haltestellen-Chaos
Am 3. November 2010 12:50 schrieb Claudius claudiu...@gmx.de: kann Dir das nicht völlig egal sein, wo Du die stop_position sowieso nochmal extra einträgst? Könnte mir, aber da ich mich selber auch schon mit der Auswertung beschäftigt habe, konnte ich den Vorteil der Platzierung auf dem Weg erkennen. Die Information zum Haltestellenstandort steckt ja im platform-Tag. Klar, man kann diese Argumentation auch umdrehen, was bleibt ist dass Du ein tag (highway=bus_stop) absichtlich entgegen dem allgemeinen (AFAIK lang und breit ausdiskuttierten) Konsens verwendest, obwohl Du sowieso Redundanzen anlegst. Ist in meinen Augen respektlos gegenüber der Community. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
Am 3. November 2010 13:30 schrieb Sven Anders s...@anders-hamburg.de: Es gibt ein neues Projekt namens Dead Drops, USB Sticks in Mauerritzen zu betonieren (vgl. [1], [2]) Wie taggt man denn sowas? Vielleicht sollte man gleich Werbung für OSM machen bevor deren Datenbank online geht? amenity=dead_drops einen Tag für tote Briefkästen finde ich gar nicht schlecht. Aber muss das auch noch in amenity landen? Ich würde dann erstmal grundsätzlich einen Tag für den Typ (hier deponierter USB-Stick) machen, und die u.g. Attribute darauf beziehen. dead_drops:interface=usb1 dead_drops:size=4GB das ist allerdings nicht die physische Größe, (und auch nicht die des toten Briefkastens, s.o.). Bei USB-Sticks wäre evtl. das Filesystem interessant. dead_drops:mounted=wall operator=? und evtl. opening_hours (wenn nicht immer zugänglich) disused=yes (wenn kaputt) disused wäre wieder auf den toten Briefkasten bezogen und nicht auf den Zustand des Sticks m.E., wenn man nicht die Auffassung vertritt, der Stick an sich sei der tote Briefkasten. webpage= (ein Webseite mit weiterer Beschreibung) AFAIK nutzt man dafür überwiegend url. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
2010/11/3 Élisée Reclus elisee.rec...@arcor.de: Am 03.11.2010 18:29, schrieb M∡rtin Koppenhoefer: AFAIK nutzt man dafür überwiegend url. website=* wie schon zweimal geschrieben. das kannst Du schreiben so oft Du willst, es sind 3,5x (26 zu 66800) so viele url in der db wie websites. Wenn man es gleichziehen wollte, würde man daher ziemlich sicher url verwenden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dead Drops, Wie taggen?
2010/11/3 Élisée Reclus elisee.rec...@arcor.de: Am 03.11.2010 18:57, schrieb M∡rtin Koppenhoefer: das kannst Du schreiben so oft Du willst, es sind 3,5x (26 zu 66800) so viele url in der db wie websites. Wenn man es gleichziehen wollte, würde man daher ziemlich sicher url verwenden. Was in den Map Features steht ist dann vmtl. auch egal? da steht, man solle url nicht benutzen und es ist durchgestrichen. Gabs dazu eine Diskussion oder Abstimmung oder so was, oder wie kommt das? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 19:31 schrieb Carsten Moeller cmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Mit welchem Programm routest Du denn? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 20:01 schrieb Carsten Moeller cmindivid...@gmx.de: Am 03.11.2010 19:42, schrieb M∡rtin Koppenhoefer: Am 3. November 2010 19:31 schrieb Carsten Moellercmindivid...@gmx.de: Man muss allerdings dann alle Wege, die auf der Strecke sind finden und schlimmstenfalls über mehrere Gigabytes hinweg cachen, um sie dann irgendwann mal aufzulösen. Man will ja schließlich am Ende die Koordinaten haben, um die Route auch darstellen zu können. sind das nicht 2 Paar Stiefel? Um die Route zu berechnen werde ich doch eine Routingtabelle verwenden, mit der Darstellung hat das erstmal nichts zu tun. Theoretisch ja, praktisch nein. Zuerst kommt ja die Segmentierung, um OSM-Daten überhaupt routingfähig zu kriegen. Dabei findet bereits eine Umschlüsselung statt. Koordinaten müssen zu diesem Zeitpunkt bereits bekannt sein, damit zeitgleich die VertexIDs und die neuen Geometrien (aufgebrochene OSM-Ways) in Zusammenhang gebracht werden können. Das anschließende Routing - wenn das dann alles korrekt umgeformt ist - findet dann natürlich nur noch auf einer Routing-Tabelle statt und nach Auffinden der Route werden die Geometrien aufgrund der gefundenen kürzesten Verbindung aus der Datenbank rekonstruiert und stehen dann direkt für z.B. OpenLayers zur Verfügung. dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 20:43 schrieb Carsten Moeller cmindivid...@gmx.de: Am 03.11.2010 20:13, schrieb M∡rtin Koppenhoefer: dann könnte man doch die Bahnlinien-relation (oder Fähre) einfach als Verbindung in die Routing-Tabelle aufnehmen, oder? Ja man könnte. Dies wäre dann faktisch die Umkehrung der Segmentierung, also das Zusammenfügen von mehreren Wegen zu einem einzigen. Wenn diese Wege - warum auch immer - auch wieder segmentiert werden müssen, dann kanns n-kompliziert werden. warum nicht einfach die ID der Relation mit dazu ablegen? Dann hat man auf einen Schlag auch wieder den genauen Weg, der zurückgelegt wird. Anders als bei Straßen und Wegen sind solche Autozug- und Fährverbindungen doch relativ trivial. Für die Fahrzeit ist da sowieso eine Tabelle viel besser als Annahmen über Durchschnittsgeschwindigkeit und Weglänge. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 2. November 2010 09:49 schrieb Walter Nordmann walter.nordm...@web.de: ich kann deine aussage leider nicht bestätigen. das wiki hält sich dazu ziemlich geschlossen. das ist doch unabhängig vom Wiki was ist die wahre postleitzahl? diejenige, die gilt? Oder anders ausgedrückt: die PLZ die die Post vergeben hat. die einzigen, spärlichen hinweise gehen in richtung lokale plz anstelle von institutieller plz. Wo steht, dass man eine andere als die real vergebene verwenden soll? Dann passe ich das gerne im Wiki an. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 2. November 2010 09:49 schrieb Walter Nordmann walter.nordm...@web.de: P.S.: Postleitzahlen werden in der Karte (anders als beim Karlsruhe Schema) mit postal_code=* eingetragen. das ist veraltet und stammt aus der Zeit vor KA. http://wiki.openstreetmap.org/wiki/Key:postal_code Key:postal_code You can tag nodes, ways, and areas with postal_code=* to describe the postal code of an area or a specific building. As part of the Karlsruhe scheme the alternative tag addr:postcode=* has been widely accepted. steht ja in dem von Dir oben zitierten Absatz auch dran. Man muss die OSM-Wiki-Terminologie am Anfang erstmal interpretieren lernen: weil es kein richtig und kein falsch geben soll in OSM, sind alles nur Empfehlungen. widely accepted ist eine Verklausulierung von richtiger. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 2. November 2010 01:23 schrieb Garry garr...@gmx.de: Ein Flugplatz bzw. Start/Landeplatz ist dagegen ein Stück Land das ausnahmslos dafür definiert ist dass dort regelmässig Boden-Luftübergänge von Fluggeräten stattfinden und von dort eine entsprechende damit verbundene Gefährdung ausgeht Gefährdungen gehen von allem möglichen aus. Boden-Luftübergänge sind keineswegs zwangsläufig das einzige Kriterium für einen Flughafen. Es wäre, wenn man es so sehen würde, ein Grund, Modellflugplätze und Flugplätze/~häfen, Raketenabschussrampen und ähnliches gleich zu taggen. Da man das nicht will (ich zumindest nicht, wir könnten ja bei Bedarf mal abstimmen), sollte man sich wohl bei der Definition noch andere Kriterien überlegen. Wenn man sich mal einen groben Überblick verschaffen will (musst Du als RC-Pilot sicherlich nicht mehr): http://de.wikipedia.org/wiki/Flugplatz Unterteilung dort in : * 1.1 Flughäfen * 1.2 Landeplätze * 1.3 Segelfluggelände * 1.4 Gelände für Wasserflugzeuge und Flugboote * 1.5 Gelände für Luftsportgeräte * 1.6 Gelände für Modellflugzeuge diese Unterteilung sieht für mich sinnvoll aus, würde ich gleich im Haupttag treffen. in OSM gibt es (für mich auf den ersten Blick erkennbar) noch kaum tags dafür: lediglich für 1.1 aeroway=aerodrome auch Taginfo hilft nicht weiter: http://taginfo.openstreetmap.de/keys/aeroway sieht so aus, als hätten die Leute wirklich 1.2 bis 1.6 als aerodrome getaggt? Finde ich absurd. Oder ist das z.T. in leisure drin? Gruß Martin wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Vielleicht sollte man hier Unterscheiden zwischen Punkt-zu-Punkt-Verbindungen in denen die Eisenbahn eine Strasse ersetzt bzw. wintersichere, kurze Verbindungen ermöglicht (Bsp. Sylt, Lötschbergtunnel, Furkatunnel, Vereinatunnel) und den Autoreisezugverbindungen bei denen man einfach nur die eigene Lenkzeit im Fernverkehr verkürzen möchte (Bsp. Lörrach - Hamburg.). finde ich viel zu kompliziert, bei einer Bahnverbindung zu unterscheiden, ob die eine wintersichere Verbindung ermöglicht oder den Zweck hat, die eigene Lenkzeit zu verkürzen. Und schon gar nicht würde ich diese Unterscheidung im Haupttag machen. Und noch weniger würde ich eine Eisenbahnschiene so taggen, dass man sie mit einem Kfz legal befahren darf (railway=rail, motorcar=yes). Wenn Du denkst, dass man einen neuen Tag braucht, um Punkt-zu-Punkt-Verbindungen in denen die Eisenbahn eine Strasse ersetzt bzw. wintersichere, kurze Verbindungen ermöglicht zu taggen, dann warte ich auf Vorschläge --- kann ja sein, dass das doch Sinn macht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multiliguale Liste mit den Keys
Am 1. November 2010 19:09 schrieb Jan Tappenbeck o...@tappenbeck.net: gibt es eigentlich irgendwo eine mehrsprachige Liste der Keys um diese in App einzubauen - die man ggf. per Download irgendwo automatisch ziehen könnte. Im planet sind die komplett enthalten, alle derzeit in Gebrauch befindlichen keys und values, einschl. sämtlicher in Gebrauch befindlicher Sprachen. Meinst Du das? Der Link ist: http://planet.openstreetmap.org/ wenn Du alle je in Gebrauch gewesenen Keys und Values haben willst, müsstest Du einschl. der History analysieren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 2. November 2010 15:50 schrieb Georg Feddern ne...@bavarianmallet.de: Beide sind real und vergeben. Institutionelle Großkunden-PLZ gibt es meines Wissens immer nur zusätzlich, die geografische PLZ ist immer vorhanden. gut, zugegebenermaßen hilft es uns nicht gerade, wenn wir beide vermischen. Ggf. wäre ein Extratag sinnvoll für Institutionelle PLZ. Abgesehen davon: Was hat eine institutionelle Großkunden-PLZ mit Geografie zu tun? Wenn die Institution innerhalb der PLZ-Leitregion umzieht bleibt die institutionelle PLZ ja unverändert. widersprichst Du Dir da nicht selbst (innerhalb der ...region vs Geografie)? ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieder mal Kartenverwendung ohne Attribution?
Am 2. November 2010 16:29 schrieb Philip Gillißen gue...@freenet.de: http://www.trackspace.de/ nicht mal ein Link zu OSM, geschweige denn ein korrekter Lizenz/Attributierungshinweis. http://www.trackspace.de/index.php?option=com_contenttask=viewid=105 Das bedeutet aber nicht, dass dieser einfach zu finden ist für einen normalen Benutzer und nicht nur für unermüdliche Google-Crawler. ja, und schon auf der Startseite gibt es z.B. dieses Bild: http://www.trackspace.de/templates/trackspace/images/startseite_software.jpg das nach üblichen Maßstäben (wie es im allgemeinen bei Karten gehandhabt wird) m.E. bereits mit einem Hinweis auf OSM und die Lizenz versehen sein sollte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multiliguale Liste mit den Keys
Am 2. November 2010 16:30 schrieb Claudius claudiu...@gmx.de: Ich denke Jan sucht Übersetzungen der Keys (und wahrscheinlich auch Values), also statt highway=footway = (DE) strasse=fussweg ach so, das ist vermutlich annähernd unmöglich (reine Übersetzungen reichen ja sowieso nicht aus, manches lässt sich auch nicht übersetzen), aber einen Ansatzpunkt bieten evtl. die JOSM Presets in den verschiedenen Übersetzungen? In einer App würde ich es sehr ungern sehen, wenn man den User tags nur aufgrund einer Übersetzung (oder auch des Originaltags) und nicht aufgrund der Definitionen der jeweiligen Tags setzen lassen würde. Auch anders rum: in einer Legende hilft es nur bedingt, wenn man nicht weiss, welche Bedeutung für ein Tag definiert wurde, nur dass ein Missverständnis da meist weniger ausmacht. Bei klassisischen (Papier)Karten funktioniert das besser, weil die verwendeten Icons Standarddefinitionen folgen, die meist kartenübergreifend gelten, aber auch da ist teilweise eine gewisse Einarbeitung in die Codierung des jeweiligen Herstellers nötig, um die Karte gut interpretieren zu können. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 2. November 2010 21:10 schrieb fx99 f...@vollbio.de: Neben den Großkunden PLZ gibt es auch Postfach PLZ. Diese sind wohl einem Postamt zugeordnet, die Empfänger können über die gesamte Gemeinde / Stadtteil verstreut sein. Hier ist der Bezug zur Adresse völlig weg. zwischen irgendwo in der Gemeinde/Stadtteil und völlig weg ist der Unterschied doch signifikant. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 2. November 2010 20:10 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 02.11.2010 10:59, schrieb M∡rtin Koppenhoefer: http://de.wikipedia.org/wiki/Flugplatz Unterteilung dort in : * 1.1 Flughäfen * 1.2 Landeplätze * 1.3 Segelfluggelände * 1.4 Gelände für Wasserflugzeuge und Flugboote * 1.5 Gelände für Luftsportgeräte * 1.6 Gelände für Modellflugzeuge diese Unterteilung sieht für mich sinnvoll aus, würde ich gleich im Haupttag treffen. Es gab da vor einiger Zeit mal eine ellenlange Diskussion über den Sinn / Unsinn dieser Unterscheidung, da eine Abgrenzung nicht möglich sei. Ich kenne mich da nicht aus. glaube ich ehrlich gesagt nicht (dass man die nicht abgrenzen kann), andere Karten schaffen das ja auch. Bei einem Segelfluggelände wird man hauptsächlich Segelflugzeuge finden, die gibt es auf einem Flughafen z.B. nicht. Modellflug-gelände / -startplatz habe ich auch noch nie mit einem regulären Flugplatz zusammen gesehen. Es werden sich noch mehr Unterscheidungsmerkmale finden lassen (gut, unbefestigte Pisten gibt es evtl. auch gelegentlich bei wichtigen Flughäfen, wobei eigentlich mittlerweile selbst in Bananenrepubliken wenigstens der Flughafen befestigt sein dürfte). Wenn es wirklich keine offizielle Unterscheidung gibt, bzw. diejenigen die sich da auskennen (ein paar Flieger haben wir ja bei OSM auch an Bord) sich da raushalten wollen (was ich mir eigentlich auch nicht denken kann), dann müssten halt die Laien sich das mal ansehen. Soweit ich die letzte Unterhaltung dazu in Erinnerung habe, gab es ein paar wenige, die lautstark reklamiert hatten, dass auch RC-Fluggelände wie Flugplätze zu taggen seien (mindestens die Landebahnen), und aufgrund dieser Diskussion dann das Thema insgesamt nicht geklärt werden konnte. Viele wurden anscheinend schlicht mit sport=motor getaggt (keine Ahnung mit welchem anderen Tag), so war es zumindest bei einer Reihe von Einträgen am Namen erkennbarDa sport=motor allgemein sehr einheitlich für alles mögliche verwendet wurde (Kartbahnen, Modellflugplätze, Motocross, Sicherheitstrainingsplätze, ...) naja, besser als nichts? Vermutlich eher ein Grund, sport=motor auch noch mal aufzudröseln. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 3. November 2010 01:11 schrieb Garry garr...@gmx.de: Gefährdungen gehen von allem möglichen aus. Boden-Luftübergänge sind keineswegs zwangsläufig das einzige Kriterium für einen Flughafen. Es Das habe ich auch nicht behauptet, aber es ist der gemeinsame Nenner der für alles gilt. ... Diese Einteilung mag für eine POI-Einteilung sinnvoll sein um im Navi den Flugplatz zu finden. Für die Darstellung eines Fluggeländes auf einer Karte ist das aber erstmal unerheblich. Da sind die Kernaussagen erstmal: Achtung Fluggelände! Lebensgefahr - unbefugtes Betreten... deshalb sind wir beim letzten Mal schon nicht weitergekommen... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feinkost
2010/11/1 fx99 f...@vollbio.de: jan99 wrote: hat einer eine Idee für Feinkostgeschäfte ? wie wär's mit deli ? +1, shop=deli wird bereits 279 mal genutzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 1. November 2010 12:07 schrieb Peter Körner osm-li...@mazdermind.de: Am 01.11.2010 08:27, schrieb Simon Poole: Ich sehe auch das Problem des OP nicht ganz Es geht einzig und allein um's Bauchgefühl. Das fehlen einer deutschen Übersetzung gibt - zumindest mir - das Gefühl, dass die Entscheider sich keine Gedanken drum gemacht haben, dass nicht jeder des englischen so mächtig ist; und das obwohl ich den Lizenztext bereits gelesen, verstanden und bestätigt habe. die meisten hätten auch nicht das juristische Verständnis, die Lizenz und Ihre Implikationen bis ins Letzte zu verstehen, wenn es eine juristisch verbindliche Übersetzung gäbe. Ich sehe es auch so, dass es Geldverschwendung wäre, eine solche über das rechtlich erforderliche Maß (Italien fordert es z.B. gesetzlich, dass es eine italienische Version gibt, damit es in Italien gilt) für alle möglichen Sprachen (und Jurisdiktionen) anzufertigen. Anwälte kosten sehr viel Geld, das ich anders besser ausgegeben sehe. Wer sich da bei der OSMF beschwert sollte sich vielleicht eher bei der dt. Regierung beschweren. Ich glaube ausserdem, dass die allermeisten der genaue Text der Lizenz nicht so wichtig ist, solange diese frei ist und bestimmte Teile wie Attribution und ggf. share-alike fordert. Sooo viel ändert sich ja nicht durch die Anpassung von Werken (die wir aber immer schon eigentlich für Daten wollten) auf Daten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 1. November 2010 12:26 schrieb fx99 f...@vollbio.de: Es wäre meiner Meinung nach viel effizienter, wenn sich eine Hand voll OSMF-ler einen verbindlichen deutschen Annahme-Text ausdenken (muss ja nicht eine eins-zu-eins Übersetzung sein), als wenn sich tausende deutscher Mapper den Kopf darüber zerbrechen und diskutieren, was denn mit dem Text gemeint ist. Einen verbindlichen dt. Text zu fordern halte ich für problematisch. Vermutlich müsste der dann wieder verbindlich ins englische übertragen werden? Es ist ja nicht so, dass man sich nicht auf dt. über die Lizenzfrage informieren kann: http://wiki.openstreetmap.org/wiki/DE:ODbL/We_Are_Changing_The_License http://wiki.openstreetmap.org/wiki/DE:ODbL/Why_CC_BY-SA_is_Unsuitable http://wiki.openstreetmap.org/wiki/DE:Open_Database_License/Implementation_Plan Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Do not use generic words for keys Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Wie ist denn nun die allgemeine Meinung: sollen es jeweils eindeutige (unique) keys sein, oder soll die Bedeutung (ggf. auch) kontextabhängig sein? Je früher man solche Fragen klärt, um so eher kann man konsistent weitermachen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 1. November 2010 18:00 schrieb Jochen Topf joc...@remote.org: operator Da kann man sich auch auf den Standpunkt stellen, dass das eher wie name ein Tag mit beliebigen textuellen Werten ist, der übergreifend benutzt werden kann. Bin ich mir auch nicht sicher. ja, wobei auch width und sowas ja nicht statistisch ausgewertet wird, sondern freie Werte üblich sind. Trotzdem will man da Klarheit haben, was gemeint ist. D.h. Definition und Dokumentation. ist Man darf m.E. nicht nur auf Taginfo und ähnliches in der jetzigen Form schielen, wie es da am einfachsten ist, eine Auswertung zu machen, evtl. müsste man dort auch nochmal eine Unterscheidung treffen, in welchem Kontext ein Tag verwendet wird. Grundsätzlich sind verschiedene Bedeutungen desselben Tags wie bei service (übrigens bisher AFAIK wenigstens mit unique values) eigentlich kein Problem, solange es bei den Kombinationen keine Überschneidungen gibt (also z.B. ein way railway und highway gleichzeitig wäre). Bisher steht eigentlich nur fest, dass unique keys die Auswertung erleichtern und es andererseits dem Mapper geringfügig schwieriger machen, da sich das Vokabular vergrößert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 1. November 2010 18:04 schrieb Jochen Topf joc...@remote.org: Dies resultiert in diesem Fall in einem Way mit nur einem Knoten. Das ist dann schlichtweg eine fehlerhafte Datenstruktur! Das Ausschneiden passiert mit dem Programm Osmosis, das verschiedene Optionen hat, um die Logik einzustellen. Wenn Du selbst die Daten ausschneidest, kannst Du Dir selbst auswählen, welche Logik Dir am besten passt. m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug (sollten unabhängig von der ausgewählten Logik nicht enthalten sein). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 1. November 2010 23:11 schrieb Stephan Knauss o...@stephans-server.de: Ich halte es jedenfalls nicht für einen Bug des Extracts wenn da ein way mit weniger als 2 Nodes enthalten ist. ich beziehe mich auf http://wiki.openstreetmap.org/wiki/Way A way is an ordered interconnection of at least 2 and at most 2,000[1] bzw. [1] http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/config/application.yml (scheint nicht zu funktionieren) wenn die Info da falsch im Wiki steht sollte man es m.E. ändern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 1. November 2010 21:02 schrieb Carsten Moeller cmindivid...@gmx.de: Hat sich eigentlich schon mal jemand hier darüber Gedanken gemacht, warum ein Laden wie Cloudmade es nicht hinkriegt, jemanden per Autozug oder Fähre nach Westerland zu routen? Ich glaube nicht, dass es denen an klugen Köpfen mangelt! die bekommen es auch nicht hin, neue Daten zeitnah in Ihre Renderings zu übernehmen, oder einen schönen Renderstil zu entwickeln, wieso sollte das ein Kriterium sein? Bei ÖPNV ist allerdings neben den Routen auch ein Fahrplan nötig, damit man sinnvoll routen kann damit --- zumindest wenn nicht jede halbe Stunde eine Fähre geht. Für die reine Route des ÖPNV reicht im Prinzip die Liste der Haltepunkte weil es keine Rolle spielt, welchen genauen Weg das Mittel dafür nimmt (Strecke und Zeit wären natürlich nicht schlecht). Fürs Routing interessant ist dann wie oben schon gesagt in erster Linie der Fahrplan. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31. Oktober 2010 09:34 schrieb Carsten Moeller cmindivid...@gmx.de: Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. komisch finde ich das nicht. Wir unterscheiden ja z.B. auch zwischen einem See und einer Badewanne. Bei all den Diskussionen sollte auch der Nutzen von OSM berücksichtigt werden. eben Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. ja, und wenn das Was alles sein kann vom Modellflughafen bis zum Großflughafen, weil man das in den Daten nicht erkennen kann, dann hätte OSM versagt. Das einzige Problem ist und bleibt natürlich die nun ausführlich geführte Ist das jetzt ein Service oder nicht-Diskussion. schön wärs, Probleme gibt's natürlich noch viele. Hier treffen tatsächlich zwei unterschiedliche OSM-Sichtweisen aufeinander. a) Nutzen, b) Straßenbewertung (WYSIWYG). Nutzen ist kein absolutes Kriterium, solange die Daten die benötigte Information enthalten wird man immer einen Nutzen daraus ziehen können. Straßenbewertung ist ebenfalls ziemlich allgemein gehalten und kann alles bedeuten. WYSIWYG ist eher ein Editorfeature als eine Datenbankregel, vermutlich meinst Du damit das zu taggen, was man vor Ort sieht. Das passt auf physische Eigenschaften wie Oberfläche, Breite etc., aber eben nicht auf die highway-Klassifikation. So z.B. scheinen level_crossings den Taggern nicht wirklich wichtig, weil sieht man ja, dass da Straße und Schiene kreuzen... Nur ein Routing-Topologie-Erzeuger sieht das eben nicht!!! doch klar, sieht er an dem gemeinsamen Node. Das level_crossing dient nur dazu, auszudrücken, dass man es wirklich so meint. Eine Schiene, auf der ein Autozug verkehrt, die wiederum eine Straße kreuzt ... ziemlich heftig, dies ohne level_crossing auseinanderzuhalten! ob da ein Autozug verkehrt oder nicht spielt überhaupt keine Rolle, solange man da nicht von der Straße auf den Zug abbiegen kann. Ja natürlich sind hier Schiene und Strasse mit dem selben Knoten verbunden, weil (WYSIWYG) ist ja so. ... (Aber ist eben Mist). wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Ich freue mich über Rückmeldungen hier oder im Wiki und würde mich auch freuen, wenn andere ihre persönliche Liste aufstellen. Das sind dann alles Schritte zu einem Konsens. Danke Jochen, finde ich allgemein sehr sinnvoll. Habe ein paar kleine Tippfehler korrigiert und ein paar Anmerkungen, mit denen ich hier anfange (bin etwas unter Zeitdruck, daher kommt vermutlich später mehr): Do not use generic words for keys Hier führst Du aus, dass man keine allgemeinen Keys verwenden/erfinden sollte. Ich kann das nicht so gut nachvollziehen. Klar haben diese dann unterschiedliche Bedeutung, je nach Kontext, aber ist das schlimm? Nimm z.B. name. Wäre es da besser street_name als Name für Straßen zu verwenden und station_name für Bahnhofsnamen? Solange es um eine allgemeine (assimilabile) Eigenschaft geht, sind universell verwendbare Keys m.E. durchaus sinnvoll. Schwierig wird es bei solchen Sachen wie width. Da ist dann teilweise schon unklar, ob es um die Durchgangsbreite oder die Breite des Objekts geht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 13:20 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Do not use generic words for keys Hier führst Du aus, dass man keine allgemeinen Keys verwenden/erfinden sollte. Ich kann das nicht so gut nachvollziehen. Klar haben diese dann unterschiedliche Bedeutung, je nach Kontext, aber ist das schlimm? Nimm z.B. name. Wäre es da besser street_name als Name für Straßen zu verwenden und station_name für Bahnhofsnamen? Solange es um eine allgemeine (assimilabile) Eigenschaft geht, sind universell verwendbare Keys m.E. durchaus sinnvoll. Schwierig wird es bei solchen Sachen wie width. Da ist dann teilweise schon unklar, ob es um die Durchgangsbreite oder die Breite des Objekts geht. ich würde das gerne noch weiter ausführen: m.E. sollten die Tags so spezifisch wie nötig aber so generisch wie möglich sein. Das ermöglicht die Verwendung derselben Tags in unterschiedlichem Kontext. Dabei muss natürlich die Eindeutigkeit sichergestellt sein. Gruß Martin PS: Entschuldigung für das assimilabile, gemeint war übertragbar, assimilierbar, so langsam scheint sich der Auslandsaufenthalt bemerkbar zu machen ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einheitliche Defitionen
Am 31. Oktober 2010 00:21 schrieb Stephan Wolff s.wo...@web.de: Ich beteilige mich gern an zielgerichteten Diskussionen. Vom Prinzip her sind alle Diskussionen hier zielgerichtet. Vielleicht kann man die Vorschläge zu Blöcken zusammenfassen, wie etwa Einheitliche Definitionen der landuse-Tags klar, dafür gibt im Wiki ja schon eine Seite: Key:landuse etc. oder Verwendung der highway-values path, footway, cycleway und Abgrenzung zu track und service sieh mal ins Archiv der Mailingliste (und ggf. ins Wiki), dieses Thema ist m.E. geklärt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Healthcare-Proposal
Am 31. Oktober 2010 17:13 schrieb Jonas Stein n...@jonasstein.de: Über den Healthcare-Proposal, der die Tags der Gesundheitseinrichtungen aufräumen soll Oh je. amenity=pharmacy wird schon gut 45000mal benutzt. Solche Aufräum-Aktionen stiften nur Chaos. Wenn das neue Proposal deutlich besser, kann man die alten doch in Sekunden umtaggen. Das könnte man schon machen. Auch ist shop=pharmacy ja gleichzeitig mit amenity=pharmacy tag-bar, aber sinnvoll finde ich das trotzdem nicht. Man könnte dann eher healthcare=pharmacy (z.B. nur für die dispensing=yes) einführen. Ein normaler shop sind dt. Apotheken jedenfalls nicht m.E. (in großen Teilen passt es schon, in wichtigen Teilen aber auch nicht). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Healthcare-Proposal
2010/10/31 Élisée Reclus elisee.rec...@arcor.de: Ja, aber wegen der massiven Kritik habe ich in Abstimmung mit !i! die Apotheken gerade rausgenommen. Da kann man dann ja später ggf. noch einen separaten Proposal raus machen. ja, das Voting fing ja auch erst am 1.11. an... Falls jemand die deutschen Beschreibungen vermisst: Nach Kritik im IRC habe ich die Seite in zwei (deutsch / englisch) aufgespalten. Du hast das Proposal in ein deutsches und ein englisches geteilt? Voten kann man aber nur für eine Version, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS und Gali leo für bessere Navigation
Am 31. Oktober 2010 17:52 schrieb Benjamin Hagemann be...@benny.de: Hallo Zusammen, ja, diese Meldung ist noch etwas speziell und Zukunftsmusik: golem: Napa: Kombination aus GPS und Galileo für bessere Navigation http://www.golem.de/1010/78985.html Es geht darum, dass u.a. Firmen IMST als Projektkoordinator, Navigon, Navteq, das Fraunhofer-Institut für Integrierte Schaltungen, die Navcert GmbH sowie der Lehrstuhl für Integrierte Analogschaltung (IAS) der RWTH Aachen und die Universität Koblenz daran forschen a) ein Empfangsmodul für GPS und Galileo für Fussgänger mit 1 m Genauigkeit entwickeln Mal sehen, ich halte das für unwahrscheinlich, vermutlich wird das US Militär (oder auch die Galileo Betreiber) dann wieder am GPS (Galileo) drehen, so dass man mit Galileo auch nur die übliche Genauigkeit hinbekommt. Die GPS Ungenauigkeit ist ja nicht technisch bedingt sondern politische Absicht (s. Genauigkeit des militärischen Teils). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 17:53 schrieb Bernd Wurst be...@bwurst.org: Am Sonntag 31 Oktober 2010, 16:48:04 schrieb M∡rtin Koppenhoefer: Das ermöglicht die Verwendung derselben Tags in unterschiedlichem Kontext. Ist das erstrebenswert? Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Aber bei Tags die Eigenschaften eines Objekts beschreiben ist es doch recht entscheidend, dass der Auswerter den Kontext kennt. Ein Tag das gleich aussieht, in einem anderen Kontext aber eine völlig andere Bedeutung hat, ist nicht unbedingt ein Vorteil. Das stimmt, aber wie ist die genaue Liste: wo macht es Sinn, und wo nicht. Eigenschaften reicht als Kriterium nicht aus m.E. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einheitliche Defitionen
Am 31. Oktober 2010 17:53 schrieb NopMap ekkeh...@gmx.de: Vom Prinzip her sind alle Diskussionen hier zielgerichtet. :-) Der war gut! danke :-) Wobei meistens gibt es ja ne Frage am Ausgangspunkt, die Beantwortung könnte man schon mal als ein Ziel definieren ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 30. Oktober 2010 22:26 schrieb Martin Simon grenzde...@gmail.com: der es genau wissen will, kommt noch das jeweilige verkehrszeichen hinzu, z.b.: traffic_sign=z241 -- damit ist die sache eindeutig. ... Ich habe nichts gegen das taggen von Verkehrszeichen - aber bitte zusätzlich, als Referenz dafür, woher die international lesbaren Restriction-tags kommen, die auch am selben Weg pappen. ... leider länderspezifisch sind - taggst du eigentlich auch Z260 statt motor_vehicle=no?) DE:z260 oder was für ein Zeichen auch immer sollte man m.E. überhaupt nicht an ways hängen, sondern nur an Nodes. In Deutschland ist das vielleicht noch eher klar, aber prinzipiell ist es immer eine Interpretation, wo bzw. bis wo ein Schild gilt. Wenn man es auf einem Node an der Position taggt, mappt man die Realität (eine Art von Richtung wäre auch nicht schlecht, ist meistens aber überflüssig). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 18:16 schrieb Bernd Wurst be...@bwurst.org: Am Sonntag 31 Oktober 2010, 17:59:55 schrieb M∡rtin Koppenhoefer: Das stimmt, aber wie ist die genaue Liste: wo macht es Sinn, und wo nicht. Eigenschaften reicht als Kriterium nicht aus m.E. Du hast ein sehr gutes Beispiel schon genannt: width. Ist es aus Sicht des Nutzers (Durchgangsbreite) oder aus Sicht des Karten- Malers (Gesamtbreite/Aussenmaße)? m.E. ist width für die Straßenbreite etabliert, d.h. bei linearen Features kann man es m.E. universell für die Breite verwenden. Auch ein Node mit barrier=gate ist eigentlich klar. Einer mit barrier=bollard oder block allerdings nicht ;-). Man könnte das aber so definieren, dass width immer die Durchgangsbreite ist --- sinnvoll wäre es IMHO. Unklar ist dabei natürlich trotzdem noch, bis zu welcher Höhe es gilt (Lichtraum), vor allem, wenn der Querschnitt nicht rechtwinklig ist, reichen Höhe und Breite zur Definition ja sowieso nicht aus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS und Gali leo für bessere Navigation
Am 31. Oktober 2010 18:39 schrieb Carsten Schönert c.schoen...@t-online.de: Genau aus diesem Grund (das GPS ist in der Hand der US Militärs) wurde vor Jahren Galileo ins Leben gerufen und ist ein europäisches Projekt. Insofern ist diese Gefahr da nicht gegeben, doch klar, auch aus europäischer Sicht spielen militärische Erwägungen da eine Rolle. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS und Gali leo für bessere Navigation
Am 31. Oktober 2010 18:49 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 31.10.2010 17:58, schrieb M∡rtin Koppenhoefer: Das ist AFAIK nicht mehr korrekt: Die aus militärischen Gründen eingeführte zusätzliche Ungenauigkeit des GPS ist seit einigen Jahren abgeschaltet. Allerdings behält sich das US-Militär vor, das aus taktischen/militärischen Gründen wieder zu aktivieren. Ich beziehe mich da auf die dt. Wikipedia: Da die Bandbreite des militärischen Signals ca. 20 MHz ist, können die 1-2 MHz Bandbreite des C/A-Codes, die zivil genutzt werden, gestört werden, ohne dass militärische Empfänger wesentlich beeinträchtigt werden. Das und die Annahme, dass heutige Konflikte regional begrenzt sind, führten zur Entscheidung, die künstliche Verschlechterung abzuschalten. und weiter: Der wesentliche Unterschied besteht darin, dass der Takt der P/Y-Codefolge im Satelliten grundsätzlich keinem künstlichen Taktfehler unterworfen wird und der P-Code auch die 10-fache Taktrate zum C/A-Code aufweist. Damit können P/Y-Empfänger die für die Positionsbestimmung wesentliche Information der Übertragungszeiten genauer gewinnen. http://de.wikipedia.org/wiki/GPS Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS und Gali leo für bessere Navigation
Am 31. Oktober 2010 19:42 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: http://de.wikipedia.org/wiki/GPS Weiter unten: Es gibt zwei Dienstklassen: * Standard Positioning Service (SPS) ist für jedermann verfügbar und erreicht eine Genauigkeit (engl. accuracy) von ca. 15 m horizontal (in 95 % der Messungen). Nach stetigen Verbesserungen vor allem durch den sukzessiven Ersatz älterer Satelliten durch Nachfolgemodelle wird aktuell eine Genauigkeit von 7,8 m horizontal garantiert (in 95 % der Messungen). Im Mai 2000 wurde eine künstliche Ungenauigkeit vom US-Militär abgeschaltet; davor betrug die Genauigkeit 100 m. Mit der vierten Ausbaustufe soll in Krisen- bzw. Kriegsgebieten eine künstliche Verschlechterung (Selective Availability) durch lokale Störung des Empfangs verwirklicht werden. * Precise Positioning Service (PPS) ist der militärischen Nutzung vorbehalten und ursprünglich auf eine Richtigkeit von 22 m (in 95 % der Messungen; die aktuelle Richtigkeit ist unbekannt) ausgelegt worden. Diese Signale werden verschlüsselt ausgestrahlt. Eine Erhöhung der Genauigkeit (0,01–5 m) kann durch Einsatz von DGPS (Differential-GPS) erreicht werden. ___ DIe Angaben des PPS sind sowieso da militärisch nur mit Vorsicht zu geniessen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 19:47 schrieb Jochen Topf joc...@remote.org: Die Frage ist mal wieder, was man mit diesen Tags machen will. Beim Namen macht es Sinn einen Tag zu haben, weil der Name eines Objektes letzlich nichts anderes ist als der Name eines anderen Objektes. Beides sind willkürliche Bezeichner, die uns Menschen helfen, auf das Ding zu verweisen. Bei der Eingabe habe ich einfach ein Eingabefeld. Beim Erstellen einer Karte, kann ich den Namen einfach mal so dazuschreiben, egal, was das Objekt genau ist. Bei einem ref sehe ich das schon anders. Für Straßen gibt es bestimmte offizielle Bezeichnungen, die wir im ref speichern. Die haben eine spezifische Struktur und Bedeutung. Wenn ich jetzt für, sagen wir, Bushaltestellen, auch einen ref-Tag nehme, weil das ja auch irgendwie eine Nummer ist, dann bringe ich zwei Sachen durcheinander. Die Bezeichnung der Bushaltestelle hat eine andere Struktur, wird von jemand anderem vergeben und auf einer Karte anders dargestellt. das ist doch aber nicht entscheidend, ob der Bezeichner von einer anderen Stelle vergeben wird oder in einem anderen Format ist. Auch international ist das ja der Fall bei highways. Wenn ich einen Tag habe, werde ich den m.E. immer öfter im Kontext interpretieren müssen, bzw. wird immer klarer, dass das auch jetzt schon so ist. Ganz absurd wird es, wenn es wie im aktuellen healthcare-Vorschlag einen Tag specialty gibt, der die Art des Mediziners angeben soll, um den es hier geht. Aber wenn ich das wiederverwenden will, z.B. mit specialty=italian an einem Restaurant oder specialty=football bei einem Sportverein. Dann habe ich total verschiedene Dinge miteinander vermischt. naja, wie man will. vermischt ist da eigentlich nichts. Dein Programm zur Auswertung muss nur schlau genug sein, die Informationen richtig zu interpretieren. Will ich jetzt im Editor eine Auswahlbox einbauen, die mir eine Auswahl der wichtigsten Werte erlaubt, dann muss ich berücksichtigen, ob ein heathcare, restaurant oder sports-Tag zusätzlich hier dran ist. ja, stimmt. Schau ich eine Statistik der Werte an, finde ich alle möglichen wild durcheinander. je nachdem, wie die Statistik aufgebaut ist. Das Wort speciality ist zu generisch, es sagt eigentlich nichts aus, außer dass hier eine hierarchische Unterordnung stattfinden will. Es wird niemals Sinn machen, die specialty-Fälle von healthcare und restaurant zusammen zu betrachten, so wie man z.B. im Falle von name gerne eine gemeinsame Suche hätte, sodass man nach Straßennamen und dem Namen von Medizinern suchen kann. das stimmt zwar, Vorteil ist aber, dass man mit einem geringen Vokabular (geringer Einstiegshürde) viele und mächtige Taggingmöglichkeiten hat. Man könnte das allerdings auch erreichen, indem man die Tags logisch aufbaut, also z.B: healthcare:specialty (oder anders rum), restaurant:specialty, ... Natürlich gibt es hier keine perfekte Definition, wie man diese Fälle auseinanderhalten kann. Es gibt eher einen fließenden Übergang. Vielleicht will man einer Brücke einen anderen Namen geben als der Straße darauf, dann wäre ein bridge_name nicht schlecht. in der Tat, oder name:bridge oder sowas. Macht da auch Sinn, weil es ja durchaus beides geben kann (dass es derzeit Sinn machen würde ist aber vielleicht auch nur eine Folge aus den unterentwickelten Brücken). Hier hilft es auch, sich zu überlegen, was denn der typische, häufige Fall ist und was eher ein Spezialfall. Ja, das ist sehr wichtig, aber teilweise auch schwierig zu beantworten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 20:11 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 31. Oktober 2010 19:47 schrieb Jochen Topf joc...@remote.org: Taggingmöglichkeiten hat. Man könnte das allerdings auch erreichen, indem man die Tags logisch aufbaut, also z.B: healthcare:specialty (oder anders rum), restaurant:specialty, ... die Frage ist bei einer Systematik zur Bildung individueller Keys dann allerdings, wie man die aufbaut. Am obigen Beispiel sieht man ja schon, dass einerseits (healthcare) ein Key genommen wurde, auf der anderen Seite ein Value (restaurant), weil amenity:specialty eben nicht (viel) weitergeholfen hätte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 31. Oktober 2010 19:51 schrieb Karl Eichwalder k...@gnu.franken.de: aber prinzipiell ist es immer eine Interpretation, wo bzw. bis wo ein Schild gilt. Das hätten die italiener gern so ;) guter Witz, aber das ist prinzipiell so. Z.B. beim Tagging von Maxspeed halte ich es mittlerweile für sinnvoll, einzelne Schilder an den Straßenrand zu taggen. Selbst wenn dann nur für eine Richtung gültig, oder ursprünglich zu weit getaggt (oder zu kurz) weil man evtl. ein Schild übersehen hat, die Info ist da und hilft weiteren Mappern beim Weiterarbeiten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Großdeutschland?!
Am 30. Oktober 2010 00:22 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Hallo zusammen, die Mapnik Karte hat keien deutsche Grenze mehr! Hat die jemand gelöscht? http://osm.org/go/0JDJ9 ja, sieht in der Tat so aus als hätte sich die Ostmark mal wieder freiwillig angeschlossen... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 30. Oktober 2010 12:36 schrieb NopMap ekkeh...@gmx.de: Bestes Beispiel ist die unsägliche Diskussion wie man so etwas scheinbar simples wie einen Radweg taggt bzw. was die Tags, die dafür im Umlauf sind eigentlich genau bedeuten sollen. Dieses Thema poppt alle paar Monate wieder auf, wenn ein verwirrter Neuling die scheinbar einfache Frage aufwirft, dreht sich jedes Mal im Kreis und hat sich seit 2008 nicht das allergeringste bischen auf eine Lösung zubewegt. Und ehrlich gesagt ist das Deine Schuld ;-) Früher war ein Radweg highway=cycleway. Man hätte das nun, als man erkannt hat dass damit alle irgendwie mit dem Fahrrad befahrbaren Wege getaggt wurden, um official (od. designated) ergänzen können. Weil aber path eingeführt wurde, der sowohl inkompatibel als Zusatztag zu existierenden highways ist, als auch eine Schnittmenge mit mehreren der bereits eingeführten Tags bildet, kam es seitdem logischerweise zu diversen Diskussionen und zu Konfusion. Andererseits ist der path durchaus sinnvoll, weil man damit nicht so unsinnige (weil subjektiv) Definitionen wie das höchste Verkehrsmittel bestimmt die Klassifikation benötigt, d.h. es werden universelle Wege möglich. Nur hätte man m.E. damit am besten cycleway, bridleway und footway deprecaten sollen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 30. Oktober 2010 00:02 schrieb Stephan Wolff s.wo...@web.de: die meisten OSM-Tags sind nicht eindeutig definiert. Regelmäßig werden hier, im Forum und im Wiki Fragen zur Verwendung der Tags diskutiert, wie z.B.: das ändert sich auch mit eindeutigen Definitionen (die wir oft haben) nicht. Deine im Folgenden gelisteten Fragen lassen sich m.E. allesamt durch Nachdenken lösen. Prämisse ist dabei, dass man ein Objekt nur als das taggt, was es ist. - Umfasst landuse=residential/industrial/retail nur die entsprechend genutzten Privatgrundstücke oder auch die dazwischenliegenden Straßen? da die Straßen nicht residential, industrial, etc. sind, sondern öffentliches Straßenland, sollten sie nicht eingeschlossen werden. (s. Grundregel oben). - Gibt width bei Straßen die Breite der Fahrbahn oder die Gesamtbreite inklusive Parkstreifen, Grünstreifen und Gehweg an? m.E. umfasst highway den befahrbaren Teil der Straße, width würde ich daher nur für die Fahrbahn verwenden. Parkstreifen sehe ich da eingeschlossen. Fraglich könnte es werden, wenn man die Gehwege explizit mittaggt (so was wie sidewalk:right=yes oder so). Man sollte m.E. einfach klar reinschreiben, dass width die Breite der Fahrbahn beschreibt (z.B. zwischen den Bordsteinkanten, bzw. zwischen den seitlichen Fahrbahnbegrenzungen (weisse Streifen). Zusätzlich könnte man dann weitere Tags einführen für die Detailhungrigen (width:physical für die real asphaltierte Fläche, einen Wert für die Gehwegbreite links und rechts, ...). Grünstreifen, Bankette, Entwässerungsgraben etc. sähe ich dann in einem landuse=highway eingeschlossen. - Gilt amenity=fuel nur für öffentliche KfZ-Tankstellen oder auch für Tankstellen für Schiffe, Flugzeuge und Schienenfahrzeuge? fuel gilt für fuel stations, mehr steht in der Tat nicht im Wiki. Nach der engl. Wikipedia zu schließen scheint sich das Wort allerdings nur auf Kfz-Tankstellen zu beziehen. Ich finde es auch ehrlich gesagt fahrlässig, einfach alle anderen der oben aufgelisteten Tankstellen so zu taggen, weil die Verwechslung doch naheliegend ist. - Wird ein Friedhofsweg für Besucher und Fahrzeuge der Friedhofsgärtner als path, footway, track oder service eingegeben? service m.E., sofern er nicht explizit für Fußgänger gewidmet ist (dann zusätzlich einen access-tag für die Gärtner: motor_vehicle=private). Da Fahrzeuge den Weg benutzen können, fallen path und footway erstmal raus. Track ist es m.E. auch nicht, da weder land- noch forstwirtschaftlich, bleibt also nur service übrig. - Kennzeichnet natural=tree nur besondere oder jeden beliebigen Baum? auch das logisch zu beantworten. Die Diskussion war daher auch 1-3 Leute gegen den Rest. - Werden auch Modellflugplätze als aeroway=aerodrome getaggt? nein. Auch das mit Menschenverstand keine Frage, oder? Manche Tags sind gar nicht auswertbar, wenn man die benutzte Definition nicht kennt. ja, ich würde sogar sagen, alle Tags sind ohne die Definition zu kennen nicht auswertbar. Aber das ist doch kein Problem sondern das System. Wie können wir zu eindeutigen Definitionen der Tags kommen? indem wir nicht ohne es vorher öffentlich anzusprechen (am besten international) wild im Wiki rumeditieren und bereits vorhandene Tags umdefinieren bzw. unausgegorene sich nicht ins System einfügende und überlappende Tags nicht einfach so reinschreiben. Indem sich mehr Leute an den Diskussionen zu Proposals beteiligen und Ergebnisse der Diskussionen hier auf den Listen auch ins Wiki übertragen werden, ... Abstimmungen im Wiki (Basisdemokratie) - kaum Schutz gegen Mehrfachstimmabgabe das ist bisher AFAIK kaum ein Problem gewesen ;-) Dazu kommt natürlich das Problem, dass viele Fragen nur international gelöst werden können, aber auch OSM-Teilnehmer, die nur wenig Englisch beherrschen, nicht ausgegrenzt werden sollten. es ist naturgemäß so, dass wer kein Englisch kann, auch nicht in einem internationalen Projekt mitdiskuttieren kann. Es gibt ja hier die dt. Liste und Forum und Wiki, aber ohne Englisch hat man in jedem Fall einen schwierigeren Stand, die dt. Übersetzungen entsprechen ja z.T: auch nciht den engli. Definitionen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 30. Oktober 2010 13:35 schrieb NopMap ekkeh...@gmx.de: Und ehrlich gesagt ist das Deine Schuld ;-) Ich fühle mich ja enorm geehrt, wieviel Einfluß auf die gesamte OSM-Community Du mir zuschreibst - aber die Einführung von path war lange vor meiner Zeit, die unterschiedlichen Fehldeutungen dieses Tags mußte ich auch erst mal recherchieren. :-) OK, sorry, dann habe ich da was durcheinandergebracht, die zitierte Seite hast Du ja erstellt, und damals die Abgrenzungsversuche unternommen. War aber auch nicht als ernste Anschuldigung gemeint. Was mich darauf bringt, daß heute ebensowenig klar ist, wie man einen typischen Wander-Trampelpfad taggt. Viele nehmen dafür path, was der ursprünglichen Intention komplett widerspricht. so weit würde ich nicht gehen. path passt schon. Ich hätte gerne noch ein Klasse darunter gehabt, wobei trail da als Wort schlecht gewählt war, weil es zumindest in einer Teilbedeutung dem entspricht, was wir als path taggen. Für Wander-trampelpfade sehe ich path als sinnvoll an, Frage war da eher für absolut informelle also spontan entstandene, nicht geplante und gepflegte, nicht gewartete Trampelpfade eine Abgrenzung zu größeren bzw. offizielleren Wegen zu schaffen. Meinen Vorschlag hatte ich auf informal_footway bzw. informal_path geändert, und bin mittlerweile bei einem Zusatzkey informal=yes gelandet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 30. Oktober 2010 12:42 schrieb Peter Wendorff wendo...@uni-paderborn.de: Ich denke aber, dass fährwege entsprechend im preprocessing genutzt werden sollten: Die Erzeugung des Routinggraphen sollte die Fährverbindung eben inklusive ihrer Zufahrtswege berücksichtigen und ein Gesamtgewicht dafür vergeben (oder so ähnlich). Ich denke nach wie vor, dass service zu wenig ist für dermaßen bedeutende Wege. Auch Autobahnzufahrten werden ja nciht als service getaggt, auch wenn man z.B. durch eine Mautstelle einfahren muss. Die Bedeutung fürs Verkehrsnetz ist mit service bei einem wichtigen Fährhafen nicht ausgedrückt. Nicht jede Zufahrt ist automatisch ein service, das ist eine Überinterpretation der Definition von Service m.E. und ein Ignorieren der Funktionsweise des highway-tags. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 30. Oktober 2010 14:02 schrieb Jochen Topf joc...@remote.org: Also: Total kaputt ist es nicht. Daher brauchen wir auch keine Revolution, die +1 Zum Beispiel in dem er sich ein Thema vornimmt und die Wiki-Doku verbessert. das ist (obwohl gut gemeint) leider zum (kleineren) Teil auch das Problem: Leute die sich ein Thema vornehmen und das Wiki verbessern. M.E. sollte man solche Verbesserungen erstmal auf der Mailingliste ankündigen und 2-3 Tage abwarten, ob Zustimmung oder berechtigte Kritik kommt, und falls Kritik da ist und ein Thema nicht einvernehmlich geklärt werden kann, dann sollte man auch nicht die Verbesserungen ins Wiki nehmen. Im Wiki sind viele Widersprüche und Ungereimtheiten verstreut, die m.E. vor allem daher kommen, dass viele gutgemeinte Edits unilateral eingestreut werden. Verbesserungen sind ja schon gut und richtig, nur sollen sie den üblichen Weg (die allgemein praktizierte Methode) beschreiben, den es oft eben noch gar nicht gibt. Und in diesem Fall (also neues Tag/Tagging-anliegen) bin ich dagegen, dass einzelne erstmal irgendwas dokumentieren, solange das nicht auch als solches gekennzeichnet ist (dafür gibt es ja speziell den Bereich Proposal mit verschiedenen Stufen vom Entwurf zum Tag). Solche Seiten wie Wie mappe ich ein A-Z oder Tagging-Beispiele urban oder so was sorgt im Endeffekt für mehr Verwirrung als wenn es die Seite nicht gäbe, weil sie (und das zeigt unser Wiki) eben nicht permanent aktualisiert werden (und unser Tagging-Schema nach wie vor ziemlich in Bewegung ist). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 30. Oktober 2010 14:18 schrieb Mike Dupont jamesmikedup...@googlemail.com: Hi, Wollte fragen, wie kann es einheitlich werden wenn man die Englischsprachigen Menschen aus der Diskussion ausschließt, weil die es gar nicht verstehen? sicherlich gibt es einige die hier mitreden wollen, Hier ist die deutsche Liste und es gibt einige, die kein Englisch können. Sicherlich werden auch auf der französischen oder italienischen Liste oder in anderen Sprachen ähnliche Diskussionen geführt. Mit den Ergebnissen kann man dann immer noch auf die internationale Ebene gehen, aber von vornherein diejenigen auszuschließen, die kein Englisch können, kann man hier auch nicht unwidersprochen fordern m.E. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beitrag zur ARD-Themenwoche - naturkostladen
Am 30. Oktober 2010 14:00 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! ich habe bei uns jetzt 2 supermarket in organic geändert. bei hotels wird ja auch nicht nach den betten-zahlen unterschieden ! was haben Hotels mit einem Supermarkt zu tun? m.E. könnte man sowas auch etwas behutsamer angehen und erstmal überlegen, was wichtiger ist: dass es ein Supermarkt ist, oder dass es ein Ökoshop ist. Und wenn man sich diese Frage gestellt hat, könnte man auch auf die Idee kommen, dass entweder shop=supermarket oder shop=organic keine gute Idee war (dann vermutlich organic). Meine persönliche Präferenz geht zu shop=supermarket, organic=yes, wobei es anders rum natürlich auch geht (ist die Frage, wie supermarktig der Laden ist). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Am 30. Oktober 2010 19:00 schrieb Karl Eichwalder k...@gnu.franken.de: path sollte man in Deutschland nur für (naturnahe) wege ohne blaues schild verwenden, quasi als ergänzung zu footway. In anderen ländern sollte man entsprechend verfahren. wenn ich da gleich mal nachhaken darf: was empfiehlst Du dann für nicht naturnahe Wege ohne Schild? Und was bedeutet in anderen Ländern entsprechend verfahren konkret? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
