Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hi ant, Am 03.11.2010, 20:51 Uhr, schrieb ant antof...@gmail.com: [...] Karten mit Layern ansprechender gestalten [...] 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. 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. 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. Viele Grüße Kay ___ 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?
Am Donnerstag 04 November 2010, 18:58:34 schrieb Tom Müller: Ich möchte eigentlich nur wissen wie konsistent z.B. Abbiegebeziehungen sind. Die Sache ist doch eigentlich logisch: Relationen an sich sind konsistent. Du kannst keine Relation machen mit einem Member der nicht existiert. Das verhindert die API. Aber die Semantik von Relationen (wie die von jeglichem anderen OSM-Objekt) kann die API gar nicht prüfen. Woher soll die API denn wissen was du meinst? Jeder kann jeden beliebigen Typ von Relation benutzen und da an Objekten eintragen was er will. Nur weil im Wiki irgendwo eine Empfehlung steht, was denn nun eine Abbiegebeziehung sein soll, ist das kein Gesetz und es gibt sicherlich irgendwo Leute die ein anderes, ähnliches aber subjektiv besseres Schema nutzen. Der Grundsatz dass bei OSM jegliches Tagging und jegliche Semantik eine individuelle Einschätzung des Mappers bzw. ein Konsens mehrerer Mapper ist führt logischer Weise dazu, dass es in der API keinerlei Plausibilitätsprüfung gibt, die über das technisch notwendige hinausgeht (also dass man keine Objekte nutzt die es nicht gibt). Die Editoren, insbesondere JOSM, versuchen manche Dinge zu verstehen und schlagen ggf. Verbesserungen vor. Das alles auf einer eher generischen Ebene, also nicht auf Abbiegebeziehungen gemünzt sondern halt für eigentlich alle Relationen geeignet. Da auch JOSM den Mapper nur unterstützen und nicht einschränken will (und soll), wird die Veränderung nicht gemacht sondern vorgeschlagen. Klickt der Benutzer auf Nein, macht JOSM auch nichts. Wieso auch, der Benutzer hat das ja wissentlich und aktiv abgelehnt. Gruß, Bernd -- Vorstellungskraft ist wichtiger als Wissen. - Albert Einstein signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Anfahrtskizze erstellen
Am Donnerstag 04 November 2010, 22:52:06 schrieb Andreas Tille: Naja, muss ist ein starkes Wort, aber praktisch wär es schon, zumal wenn man weiß, daß dort in der Gegend noch einiges fehlt und dann ist die Live-Karte einfach aktueller. Bei einfachen Besuchern gibt es ab und an mal Verwirrungen wenn sie auf einer interaktiven Karte versehentlich das Mausrad benutzen oder da drauf klicken. Es kann daher (je nach erwartetem Publikum) ein großer Vorteil sein, eine statische Karte zu machen, die sich nicht unerwartet verhält wenn der Benutzer keine Efahrung mit solchen Karten hat. Bzgl. der Aktualität kannst du auch die entsprechenden OSM-Tiles als statische Bilder (die URL ändert sich ja nicht) einbinden und deine Markierungen per transparentem Bildchen drüber legen. Ist zwar vielleicht initial etwas mehr Aufwand, löst aber das Problem dass sich viele Leute in der Karte verzoomen und die dadurch wertlos wird. Gruß, Bernd -- Pessimismus wird nur von den Optimisten verbreitet. Die Pessimisten sparen ihn für schlechtere Zeiten auf. - Gabriel Laub signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Hallo, Am 04.11.2010 23:12, schrieb Peter Herison: Aus diesem Grund habe ich die Tracks alle aufgetrennt, so dass ich immer Stueckchen zwischen Kreuzungen habe. Nun stehe ich vor dem Problem sie moeglichst speichersparend moeglichst an einem Stueck wieder zusammen zu setzen. Zum Teil muessen die Stueckchen auch verdoppelt und in umgedrehter Reihenfolge wieder eingefuegt werden (Sackgassen). Das geht mit QLandkarteGT: http://qlandkarte.org/ Man kann Tracks aufteilen, umkehren und miteinander Verbinden. Das ganze kann mit einer OSM-Karte oder einer Garmin-Vektorkarte hinterlegt werden. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten für Farbenblinde (Was: Re : Neu: Ein schwarz/weißer Base-Layer)
Hallo Kay, 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. Ich bin per Zufall vor ein paar Tagen über diese Seite hier gestolpert: http://gmazzocato.altervista.org/colorwheel/wheel.php Vielleicht hilft sie ja dem einen oder andren hier beim Erstellen seiner Karten.. :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tags für gesprengte Häuser?
Am 04.11.2010 10:52, schrieb Wolfgang: Wie tagt man Ansammlungen von Betonteilen, wenn z.B. 5-stöckige Plattenbauten gesprengt, aber seit 5 Jahren nicht abtransportiert wurden? Sind das Dünen aus Beton? Oder basted buildings? Oder doch nur Brownfields? Beispiel: http://www.addicks.net/gallery/osm/DSCF3173 (ehemalis baugleiches Gebäude direkt daneben: http://www.addicks.net/gallery/GeoCaching/DSCF3208 ) Ich würde brownfield nehmen. Vielleicht mit Zusatztag building=destroyed oder so. wurde es auf Haiti nicht als building=collapsed getaggt? http://taginfo.openstreetmap.de/keys/building building=ruins sehe ich da noch. Da fällt mir ein, dass ich eine abgebrannte Villa mal als collapsed getaggt habe. 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. ;-) Chris ___ 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
Re: [Talk-de] Wie Anfahrtskizze erstellen
Bernd Wurst be...@bwurst.org wrote: Es kann daher (je nach erwartetem Publikum) ein großer Vorteil sein, eine statische Karte zu machen, die sich nicht unerwartet verhält wenn der Benutzer keine Efahrung mit solchen Karten hat. Die kann man sich ohne große Arbeit hier: http://dev.openstreetmap.de/staticmap/wizzard/ und hier: http://ojw.dev.openstreetmap.org/StaticMap/ zusammenklicken. Sven -- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. (Anselm Lingnau in de.comp.os.unix.discussion) /me ist gig...@ircnet, http://sven.gegg.us/ im WWW ___ 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] Tongrube taggen
Moin, M∡rtin Koppenhoefer schrieb: 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. 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 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. ich habe es jetzt nochmals mehrfach überschlafen - und eben die deutsche Seite mit Erläuterungen an das englische Original angepasst. Wer jetzt daraufhin mit Steinen werfen will, wird mich schon irgendwie finden. Gruß Georg ___ 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 05.11.2010 12:13, schrieb M∡rtin Koppenhoefer: 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. Mach ein Proposal (abwärtskompatibel zu landuse) und gut 'is. ;-) Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geschätekuddelmuddel und anderes
Hallo Ich habe hier eine Geschäft da ist drin: Bäcker, Post, Computer mehr oder wenig ein Raum, nicht allzugroß. Wie kennzeichne ich? Post wäre für mich das wichtigste, wenn ich aber Bäcker oder Computer dazu füge springt die Kennzeichnung um (OSM) was ähnliches: hier gegenüber ist son Fitnesscenter im gleichen Gebäude ist ne Schmiede/Metallbau. alles die gleiche Hausnummer Grüße aus der Eifel Steffen ___ 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] Gebäude-Mapping
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. Das erinnert etwas an die site relation wo parkplaetze zu einkaufscentren gehoeren. Koennte doch auch an sowas adaptiert werden. Fuer Gebaeude ueber mehrere Etagen war site und level bisher hilfreich. Leider kuemmert sich keiner der großen renderer drum so das sachen die uebereinander sind auch so angezeigt werden. Im einkaufcenter der fastfood imbiss unter der pizzaria unter dem Restaurant ___ 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] Neu: Ein schwarz/weißer Base-Layer
Am 05.11.2010, 13:35 Uhr, schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: 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.Ä.). Naja, ich wollte ja zusätzlich einen mit noch reduzierter Information haben. Vielleicht (offizielle Frage an alle) sollte ich noch einen Layer generieren, der keine Straßen enthält? Evtl. möchte jemand die Straßen extra generieren und drüberlegen, z.B. streng nach width gerendert... Ich werde u.a. noch die Hausnummern aus dem reduzierten S/W-Layer rausnehmen (Widerspüche?) damit man die Möglichkeit hat, die Hausnummern als extra Layer drüberzurendern. Somit würde das Problem umgangen, dass die Hausnummern oft zu Gunsten von Icons oder anderen Texten unterdrückt werden. 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. Eigentlich: nein! Alles was schwarz/weiß dargestellt ist sollte genau für die betroffene Karte *keine* Rolle spielen. Sie soll lediglich dazu dienen, dass man weiß wo man ist. Die gewünschte Information soll im Layer darüber angezeigt werden. Viele Grüße aus Paris, Kay ___ 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
Hallo M∡rtin, ... ... 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 ... 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). ja, da müsste man Mal ran Ebenso natural strukturieren! ... Hm, bin gerade mal auf diese Wikipediaseite gestoßen: http://de.wikipedia.org/wiki/Landnutzung interessant 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. 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. 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. Hier wäre der Begriff natural zu diskutieren: ... natürliche Elemente, wie z.B. Landschaften oder geologische Gegebenheiten, ... natural features, mostly in terms of habitats and geological features ... die deutsche Übersetzung stimmt schon nicht: von landscape ist im Englischen nicht die Rede (möchte nicht wissen, wie es in anderen Sprachen aussieht). Zum Anderen ist (sehr) interessant, _was_ die Nutzer als natural taggen; siehe Diskussionen um natural=wood und landuse=forest. natural ist m.E. schon ein wertvoller Tag. ... 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 ... :) Weitere Landcover Klassifikationsbeispiele finden sich z.B. bei GLOBCOVER http://ionia1.esrin.esa.int/docs/GLOBCOVER_Product_Specification_v2.pdf ab Seite 20. grobes Dokument (läd schlecht ... ). http://wdc.dlr.de/data_products/SURFACE/LCC/diplomarbeit_u_gessner_2005.pdf Seite 24 http://www.eea.europa.eu/publications/COR0-part1/at_download/file http://www.umweltbundesamt.at/fileadmin/site/umweltthemen/raumplanung/1_flaechennutzung/corine/CORINE_Nomenklatur.pdf http://www.corine.dfd.dlr.de/media/download/nutzerseminar19_keil_et_all.pdf ... das sind natürlich nur europäische Klassen. 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. landcover deckt doch die Begriffe landuse natural ab - bzw. umgekehrt(?!?). landcover bringt OSM und die user auf ein Maschinenniveau, ist ein Verlust an Genauigkeit/Info/Wertigkeit. landcover ist der plumpe tag einer Maschine und nicht Sache von OSM. Wir sind weder optische Geräte noch Rechner. Landcover (CLC) ist faszinierend, der Begriff bringt OSM aber keinen Mehrwert. Mit ergänzenden Tags ist landuse natural m.E. ausreichend und - schöner. Wofür (bloß) sollte ich landcover nehmen? Wo würden denn landuse oder natural nicht ausreichen? ... viele Grüße, t. ___ 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 13:35 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: 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. hier gibt es noch eine Karte in Graustufen: http://osmwms.itc-halle.de/ Vielleicht gefällt Euch die besser. Falk ___ 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] Landuse, landcover, natural, landscape WAS Re: Tags für Wüstengebiete
Am 05.11.2010 16:17, schrieb M∡rtin Koppenhoefer: landuse sollte m.E. die Bodennutzung beschreiben, landcover die Bodenbedeckung, und natural bleibt für die geografischen features. Sehe ich grundsätzlich auch so. Aber warum ein neues (?) Tag landcover einführen, wenn es das etablierte surface auch tut? Die Bedeutung ist m.E. die gleiche und es verhindert, dass es wieder mehrere Tags für die gleiche Eigenschaft gibt. Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschätekuddelmuddel und anderes
Am 05.11.2010 13:00, schrieb Steffen Heinz: Hallo Ich habe hier eine Geschäft da ist drin: Bäcker, Post, Computer mehr oder wenig ein Raum, nicht allzugroß. ich hab ne Lösung gefunden im Netz und hoffe das das recht ist: einen Rahmen ziehen, diesen mit der Hausnummer versehen und alles reinpacken was unter dieser Hausnummer angeboten wird, was getan wird. Hat ne ganze Weile gedauert bis ich die Lösung endlich hatte - es ist halt die Kunst die richtigen Wörter zum Suchen zu haben Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Original-Nachricht Datum: Fri, 5 Nov 2010 10:08:48 +0100 Von: M∡rtin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen? ja, man sollte einfach mal ins Wiki schreiben, dass width die Fahrbahnbreite ohne Gehsteige enthalten sollte. Im Wiki dämmert viel Information vor sich hin, ohne von der Mehrheit beachtet zu werden. Tags ohne Sichtbarkeit auf der Karte haben wenig Chancen überhaupt wahrgenommen zu werden. Ausserdem wurde ja das Wiki von höherer Stelle als reines Vorschlagswesen eingestuft ;) ja, oder auch schmaler. In Z18 ist die OSM-Straße meist schmaler als die Realität. Stimmt, Fällt z.B. hier unangenehm auf: http://www.openstreetmap.org/?lat=52.08868lon=8.69753zoom=17layers=B000FTF In dieser Zoomstufe wird die vorhandene Fläche nicht effektiv zur Darstellung der Fahrbahneinzelheiten genutzt. Möglich ist z.B. diese Darstellung (noch ausbaufähig): http://img214.imageshack.us/img214/2618/bosmcrossing2.png Dass es GoogleCo (noch) nicht hinbekommen, so aufgelöst darzustellen, da auch z.B. GDF hier alles andere als optimal ist, ist eine andere Sache. Aber OSM will doch in jeder Beziehung anders und vor allem besser sein als das ewige Vorbild. Gruesse Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
so einen aehnlichen vorschlag gabs schonmal in der diskussion wollte es aber lieber jemandem mit besserem verstaendnis der engl sprache ueberlassen. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site M∡rtin Koppenhoefer wrote: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenverzeichnis aufgeräumt
Hi, ich habe mir gerade [2]angesehen. Was bedeutet denn am Anfang der Seite der Hinweisblaken mit This page has been suggested for clean-up. Please Discuss. ?? Gruß hike39 Am 04.11.2010 10:57, schrieb Jan Tappenbeck: hi ! da die Seite mit den Straßenverzeichnissen [1] extrem lang wurde habe ich diese nach den Bundesländern einmal aufgeteilt. Nun wäre es noch nice to have die Anfragen an die Kommunen [2] aufzuteilen - vielleicht können sich die betroffenen dem einmal annehmen. Gruß Jan :-) [1] http://wiki.openstreetmap.org/wiki/Stra%C3%9Fenverzeichnis [2] http://wiki.openstreetmap.org/wiki/Stra%C3%9Fenverzeichnis#Anfragen.2C_die_an_Kommunen_gestellt_wurden ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frage bezüglich Landes-, Stadt- und Stadteilgrenzen
Hallo, sehe ich es richtig, dass ein boundary=administrative admin_level=9 nur _in_ einem boundary=administrative admin_level=8 liegen kann? Und ein boundary=administrative admin_level=8 dementsprechend auch nur _in_ einem z.B. boundary=administrative admin_level=4? Oder ist das ein Trugschluß? Danke Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 05.11.2010 13:22, schrieb M∡rtin Koppenhoefer: 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. Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit Komzpa (Entwickler von Kothic) abgestimmt. Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen Proposal-Prozess einzubringen, aber hier passt das vielleicht rein, und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich willkommen. Gruß Peter [1] http://wiki.openstreetmap.org/wiki/User:Jongleur/MultiLevel ___ 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
Hallo M∡rtin, ... ... ... 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. das cover kann sich doch aus der Flächengröße ergeben? beim Rendern kann man zu kleine Flächen als Bäumchen darstellen, wenn jemand Unterschied sehen will? ... ... Wofür (bloß) sollte ich landcover nehmen? 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. Für sand am Strand? natural=beach (meist naturdominiert, ausser einigen künstlich erhaltenen für Touris) Für Fels am Strand? natural=rock? Für Wälder wo keine Bäume wachsen (landuse=forest, landcover=scrubs), Niederwald ist landuse=scrub oder natural=scrub (natürliche Extremstandorte) für Grassflächen, die keine Wiesen sind, hatten wir oben in einem Thread, ich denk, das war landuse=grassland und landuse=meadow für die Wiese für Wüsten (natural=desert), ja 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 ;) surface oder material wäre da naheliegender - in Verbindung mit einem Elterntag. ... landuse sollte m.E. die Bodennutzung beschreiben, landcover die Bodenbedeckung, und natural bleibt für die geografischen features. landuse = Bodennutzung (meadow, field, forest, residential, ...) landcover = Bodenbedeckung (gras, vegetables, trees, garden, ...) natural = geografische features (bog, ?, conifers, Rosengarten, ...) wäre irgendwie machbar, aber überzeugt mich noch nicht richtig. Es geht ja um das Strukturieren der Userdeutungen/Begriffsbildung. Und da muss man wohl - bei dem breiten Spektrum an usern, die mit den Objekten manchmal nichts weiter zu tun haben - mal ein paar Worte (mehr) in den Pool werfen ... (auch der Unterhaltung wege) und sehen, was hängen bleibt. mal sehen, wie es landcover ergeht. ... viele Grüße, t. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Am 05.11.2010 06:44, schrieb Christian Knorr: Am Donnerstag 04 November 2010, um 23:12:29 schrieb Peter Herison: moeglichst an einem Stueck wieder zusammen zu setzen. Da fällt mir jetzt JOSM ein. Das kann doch osm nach gpx exportieren. Musst halt nur vorher Ballast abwerfen - ich weiß ja nicht wie groß das Gelände ist. Zum Teil muessen die Stueckchen auch verdoppelt und in umgedrehter Reihenfolge wieder eingefuegt werden (Sackgassen). Wofür das? Brauchst Du das zum navigieren? Wenn ich Tracks aneinander haenge, deren Ende und Anfang nicht dicht beieinader liegen zeichnet das GPS60 eine lange Gerade dazwischen. Das Ganze ist, wie geschrieben, nur als Orientierung gedacht, um sich im Gelaende besser orientieren zu koennen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele GPX-Tracks sinnvoll vereinen
Moin moin Danke fuer die Tipps, aber ich suche weniger einen Editor, sondern ein Programm, das mir die optimale Reihenfolge fuer die Stueckchen raussucht, und zusaetzlich noch so intelligent ist, bei Sackgassen den Weg zureuck mit einzuberechnen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
M∡rtin Koppenhoefer dieterdre...@gmail.com [Fri, Nov 05, 2010 at 01:29:51PM CET]: 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? So weit habe ich nicht gedacht. Die x- und y-Koordinaten der Seile sind unabhängig von ihren Höhen interessant, weil man bei drohendem Eisfall nicht drunter langgehen sollte. (Dann ist allerdings auch das gesamte Gelände für Zutritt verboten.) Aber ok, wenn man schon mal dabei ist: Wenn man ein Linienmodell machen wollte, sollten die Stützen 2 verbundene Nodes jeweils übereinander haben, Ja, mit passenden height-Tags. also einen vertikalen Way (da schonmal viel Spaß mit den gegenwärtigen Tools), Nur wenn man den Mast in senkrechter Richtung modellieren möchte. Da wäre ich aber zufrieden, wenn ein Node mit Tags man_made=tower, tower:type=communication, height=360 den Mast modellierte. Auf dieselbe Koordinate würden dann die Anknüpfungspunkte mit entsprechendem height als einzigem Tag stehen. Bei so etwas wie dem Sonnensegel am Potsdamer Platz könnte ich mir auch vorstellen, einzelne Ecken mit einem height-Tag zu versehen. Mit den gegenwärtigen Tools ist das machbar, macht aber keinen großen Spaß. Ich habe mal aus einer Laune heraus das Atomium eingezeichnet, war aber dann nicht sehr stolz auf das Ergebnis. Aber solche Gebäude gibt es ja auch nur ein paar Mal. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
M∡rtin Koppenhoefer dieterdre...@gmail.com [Fri, Nov 05, 2010 at 01:22:20PM CET]: [...] 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. Du bist da ja Experte, ich musste irgendwann mal lernen, dass in bestimmten Plänen Brücken durch ihre Widerlager angegeben sind. 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 Da finde ich ja immer den Wert yes verschwendet und gebe auch so etwas an wie bridge=pontoon. (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. Ein Seil als Bauwerk anzusehen finde ich fast noch abartiger als eine Treppe als Spezialform einer Landstraße zu taggen. Im Bsp. Sony Center war das mit building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht unbedeutend. Eben drum, yes sollte man nehmen, wenn man es nicht spezifischer haben möchte. (Eigentlich wäre highway=yes in der Hinsicht klarer als highway=road.) 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. So wie hier? http://www.openstreetmap.org/browse/way/56007564/ -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 04.11.2010 22:37, schrieb Chris66: Am 04.11.2010 22:14, schrieb Garry: 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. Genau. Siehe Zu- und Abfahrten zu Autobahnraststätten, die meist auch als service getaggt sind. Bin zwar kein Routerprogrammierer, aber einen Check ob eine service-Road mit einer route=ferry verbunden ist (um sie für's Routing intern höher zu stufen) stelle ich mir nicht schwierig vor. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Chris, und das ist eben der Irrglaube vieler. Das ist genau der Grund, welcher die Router tötet. Dies ist mit einem LookAhead verbunden, der, solange die Datenmenge klein ist, z.B. Städte oder max. Bundesländer, noch einigermaßen performant zu berechnen ist. Im Länder- oder Kontinent-Rahmen ist die Rechenzeit dann unerträglich. Dann kommen Heuristiken ins Spiel. Zu bedenken ist hierbei auch die Tatsache, dass nach einer Ferry ein Service, dann noch ein Service, vielleicht noch ein Service und dann erst ein highway=höher folgt. Um das zu greifen, lohnt es sich kaum noch irgendwas zu betrachten, sondern stattdessen gleich alle Services mit einzubeziehen oder eben auszublenden. Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
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? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage bezüglich Landes-, Stadt- und Stadteilgrenzen
On Fri, Nov 05, 2010 at 06:27:23PM +0100, Tom Müller wrote: Hallo, sehe ich es richtig, dass ein boundary=administrative admin_level=9 nur _in_ einem boundary=administrative admin_level=8 liegen kann? Und ein boundary=administrative admin_level=8 dementsprechend auch nur _in_ einem z.B. boundary=administrative admin_level=4? Oder ist das ein Trugschluß? Noe - das passt so - Die administrativen grenzen sind immer Absteigend. Es kann sein das sie Deckungsgleich sind - aber dann sollten die nur einmal existieren. Also z.b. das thema Kreisfreie Stadt - Waere ja quasi admin_level 6 und admin_level 8 - Wobei nur ersteres existieren sollte. Typischerweise sollten sogar immer mehrere admin_level a-1 innerhalb eines admin_level a sein ... Flo -- Florian Lohoff f...@zz.de Professionell gesehen bin ich zu haben signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Hallo Jan, Am 05.11.2010 21:04, schrieb Jan Tappenbeck: Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Wat nu? Netbook oder Tablet? Ubuntu Netbook Edition? JAVA Embedded? Das Thema interessiert mich, da ich auch mit dem Gedanken spiele mir was kleines anzuschaffen. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Hallo, Am Freitag 05 November 2010 21:04:24 schrieb Jan Tappenbeck: Hi ! wie intensiver ML-Leser sicherlich mitbekommen haben bin ich seit dem Sommer Netbook-Anwender u.a. für JOSM. Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Was mich aber seit längerem stört ist die Tatsache das einige Dialoge und teilweise auch einige Funktionen nicht gerade Netbook tauglich sind. Es wäre aus meiner Sicht ein Anfang wenn einige Dinge ergonomischer wären - als Beispiel die Überdimensionalität des Einstellungsdialog den man immer nur mit Mühe und Not geschlossen bekommt. Nun wollte ich mal hören, ob es zwischenzeitlich weitere Anwender gibt die über dieses Problem zu kämpfen haben. Josm ist auf Netbooks nicht benutzbar. Die Menüs sind längenmäßig einfach Overkill. Das ist hier auch schon mal geschrieben worden. Ich verwende hier osm2go. Das muss allerdings für Linux-Systeme allerdings im Source runtergeladen und übersetzt werden. Ist aber ganz einfach. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 05.11.2010 10:20, schrieb M∡rtin Koppenhoefer: Am 4. November 2010 22:14 schrieb Garrygarr...@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. 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. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Hallo Johannes, Hallo Martin, Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen des Funkmastes, sondern um dieses allgemeine Konzept für gestückelte Gebäude, das ich mal in den Raum stellen wollte. (wie wär's mit man_made=cable, cable=suspension als Mitglied in einer Building-Relation zusammen mit dem Mast und den Widerlagern?) Am 5. November 2010 13:22 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: 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. OK, habe ich unterschlagen. ;-) Ja, nicht unbedeutend, nur tritt es leider damit immer noch als eigenständiges Gebäude auf. 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. Ja, schön illustriert werden diese Möglichkeiten ja bereits z.B. bei www.osm-3d.org . Beispiele für Gebäude, die unterschiedliche Stockwerkszahlen haben und bei denen ich damit unzufrieden bin, daß sie derzeit nach dem 'alten' Schema als Sammlung einzelner Gebäude getaggt sind, befinden sich z.B. auf diesem Campus (das Hauptgebäude mit Mensa und das Gebäude der Fakultät 06 im Norden): http://osm.org/go/0...@ggdra-?layers=o Vielleicht kriegen wir da etwas auf die Beine gestellt, das durchdacht ist und Akzeptanz unter den Mappern und Renderern finden kann... :) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 21:43, schrieb Wolfgang: Hallo, Am Freitag 05 November 2010 21:04:24 schrieb Jan Tappenbeck: Hi ! wie intensiver ML-Leser sicherlich mitbekommen haben bin ich seit dem Sommer Netbook-Anwender u.a. für JOSM. Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Was mich aber seit längerem stört ist die Tatsache das einige Dialoge und teilweise auch einige Funktionen nicht gerade Netbook tauglich sind. Es wäre aus meiner Sicht ein Anfang wenn einige Dinge ergonomischer wären - als Beispiel die Überdimensionalität des Einstellungsdialog den man immer nur mit Mühe und Not geschlossen bekommt. Nun wollte ich mal hören, ob es zwischenzeitlich weitere Anwender gibt die über dieses Problem zu kämpfen haben. Josm ist auf Netbooks nicht benutzbar. Die Menüs sind längenmäßig einfach Overkill. Das ist hier auch schon mal geschrieben worden. Ich verwende hier osm2go. Das muss allerdings für Linux-Systeme allerdings im Source runtergeladen und übersetzt werden. Ist aber ganz einfach. Gruß, Wolfgang das werde ich dann auch nochmal ausprobieren - wenn fragen sind weiß ich ja schon wenn ich fragen muss. hast dich geoutet. gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 21:24, schrieb René Falk: Hallo Jan, Am 05.11.2010 21:04, schrieb Jan Tappenbeck: Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Wat nu? Netbook oder Tablet? Ubuntu Netbook Edition? JAVA Embedded? Das Thema interessiert mich, da ich auch mit dem Gedanken spiele mir was kleines anzuschaffen. Grüße René hi ! habe ein ASUS T100MT - wenn ich die Bezeichnung richtig in Erinnerung habe. Das mit der Auswahl von Punkten über Stifte ist noch etwas schwierig und ungenau. Mit der Maus ist das besser. Bitte vergesse das nicht. Gibt auch eine Wiki-Seite dazu und ein Anfang für ein spezielles PlugIn. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Garry schrieb: Am 05.11.2010 10:17, schrieb M∡rtin Koppenhoefer: 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. Sollte nur eine Beschreibung bzw. Auslegungsvariante von service sein, für den Router taugt das so alleine nicht, also entweder Zusatztag oder gleich einen highway-tag für solche Zufahrten auf weiterführende Verkehrsmittel. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Zusatztag wäre - denke ich - eine gute Kompromisslösung und zudem auch angenehm pragmatisch. Die Services würden so unberührt bleiben und einfach nur noch einmal näher beschrieben werden. Dafür braucht man noch nicht einmal vor Ort zu sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
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. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 21:43, schrieb Wolfgang: Hallo, Am Freitag 05 November 2010 21:04:24 schrieb Jan Tappenbeck: Hi ! wie intensiver ML-Leser sicherlich mitbekommen haben bin ich seit dem Sommer Netbook-Anwender u.a. für JOSM. Nun ist einiges an Zeit vergangen und auch Ubuntu unterstützt jetzt auch TablePc-Funktionen. Was mich aber seit längerem stört ist die Tatsache das einige Dialoge und teilweise auch einige Funktionen nicht gerade Netbook tauglich sind. Es wäre aus meiner Sicht ein Anfang wenn einige Dinge ergonomischer wären - als Beispiel die Überdimensionalität des Einstellungsdialog den man immer nur mit Mühe und Not geschlossen bekommt. Nun wollte ich mal hören, ob es zwischenzeitlich weitere Anwender gibt die über dieses Problem zu kämpfen haben. Josm ist auf Netbooks nicht benutzbar. Die Menüs sind längenmäßig einfach Overkill. Das ist hier auch schon mal geschrieben worden. Ich kenne zwei Leute die mit JOSM auf dem Netbook anscheinend ganz gut klarkommen. Klar, mit Einschränkungen muß man dabei leben. Es sollten halt die Leute mit Netbooks und dessen spezifischen Problemen, *spezifische* Problembeschreibungen im JOSM trac hinterlegen Menu xy ist auf einem Display mit 800*600 Pixeln zu lang - dann können die JOSM Entwickler schauen, ob da was zu machen ist. Nur rummosern das geht nicht hilft nicht wirklich weiter. Gruß, ULFL P.S: Das Hauptkriterium beim Kauf meines Netbooks war für mich die Displayauflösung von 1024*768 Pixeln. Ich wußte warum ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Martin Simon grenzde...@gmail.com [Fri, Nov 05, 2010 at 09:57:52PM CET]: Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen des Funkmastes, sondern um dieses allgemeine Konzept für gestückelte Gebäude, das ich mal in den Raum stellen wollte. Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso, aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Marktflächen/Parkplätze
Hallo, in Hamburg gibt es viele Marktfächen, die zu Nicht-Marktzeiten als Parkflächen genutzt werden. amenity=markingplace;parking ? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Am 05.11.2010 22:24, schrieb Ulf Möller: 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 Ich hab da in letzter Zeit die Menus auch in diesem Hinblick etwas umgebaut, sollte aktuell bei 800*600 kein Problem mehr sein. ungünstig bei Vorführungen für OSM-Einsteiger, aber beim normalen Editieren braucht man das nicht unbedingt. Was soll das denn bedeuten ;-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
Hallo, Am Freitag 05 November 2010 22:24:45 schrieb Ulf Möller: 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. Unbenutzbar ist außerdem das Menü Werkzeuge. Das Menü Einstellungen ist verschiebbar, wenn die ALT-Taste festgehalten wird. Die Abhilfe wäre so einfach: Ein Scrollbar an den Menüs Werkzeuge und Vorlagen. Meine Abhilfe osm2go. Gruß, Wolfgang ___ 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. Einer war sogar so fleißig, Landebahnen zu taggen, die nur in seinem Kopf existieren - nämlich solche auf Modellfluggeländen, die schlicht eine Rasenfläche ohne Markierung und jeglichen linearen Charakter... ...denn es wird ja bereits so schön gerendert... Zum eigentlichen Thema: Wenn eine wichtige Verkehrsverbindung über ein Fährterminal und eine Fähre führt, sollten die dort eingeschlossenen Wege selbstverständlich die Klassen beibehalten, unabhänging von Geschwindigkeit (das berücksichtigen selbst simple Router schon separat) und Breite. Auch Ortsdurchfahrten von Bundesstraßen (immer überregionale Verbindungen) werden heutzutage aus Gründen der Sichertheit und des Komforts für Fußgänger und Radfahrer schmaler (breitere Bürgersteige) und langsamer ausgebildet, als es möglich wäre und früher praktiziert wurde, wenn die beengten Platzverhältnisse dazu Anlass geben. Die paar dm und km/h weniger ärgern vielleicht den Autofahrer, ändern aber nichts an der Verbindungsfunktion. Daher gehen wir dort auch nicht auf secondary, tertiary oder residential herunter. 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 22:29 schrieb Johannes Huesing johan...@huesing.name: Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso, aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. [x] check! ;-) ___ 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: Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit Komzpa (Entwickler von Kothic) abgestimmt. Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen Proposal-Prozess einzubringen, aber hier passt das vielleicht rein, und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich willkommen. Hallo Peter! Das Schema war mir noch gar nicht über den Weg gelaufen. Vielleicht kann man die Vorteile aus allen Ansätzen kombinieren. :-) Du schneidest dabei deine Gebäude horizontal, ich hatte eher eine vertikale Unterteilung im Sinn (bei deinem Beispiel(von links nach rechts): A: [7 Stockwerke], B: [5 Stockwerke, beginnend mit dem 3.], A: [7 Stockwerke]). Damit könnte man alles in einem Abwasch erledigen und sowohl solche Durchlässe als auch unterschiedliche Dachhöhen darstellen. Hat das horizontale schneiden einen Vorteil dem gegenüber, den ich übersehe? Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 05.11.2010 23:01, schrieb Martin Simon: Am 5. November 2010 18:36 schrieb Peter Wendorffwendo...@uni-paderborn.de: Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit Komzpa (Entwickler von Kothic) abgestimmt. Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen Proposal-Prozess einzubringen, aber hier passt das vielleicht rein, und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich willkommen. Hallo Peter! Das Schema war mir noch gar nicht über den Weg gelaufen. Vielleicht kann man die Vorteile aus allen Ansätzen kombinieren. :-) Dass Dir das noch nicht über den Weg gelaufen ist, hab ich mir gedacht; bisher hab ich es auch noch praktisch nicht beworben, und (außer in meiner Bachelorarbeit als Randnotiz) nirgendwo verlinkt. Im Grunde genommen ist das im momentanen Zustand ein Abfallprodukt von wie mappe ich ;) Ich plane aber, in den nächsten Wochen/Monaten daran weiterzubasteln und es auch in einen normalen Proposal-Prozess einzubringen. Auch in der Hinsicht sind mir Kommentare und Verweise zu anderen Schemata natürlich willkommen. Du schneidest dabei deine Gebäude horizontal, ich hatte eher eine vertikale Unterteilung im Sinn (bei deinem Beispiel(von links nach rechts): A: [7 Stockwerke], B: [5 Stockwerke, beginnend mit dem 3.], A: [7 Stockwerke]). Damit könnte man alles in einem Abwasch erledigen und sowohl solche Durchlässe als auch unterschiedliche Dachhöhen darstellen. Hat das horizontale schneiden einen Vorteil dem gegenüber, den ich übersehe? Bei den Universitätsgebäuden in Paderborn hat das horizontale Schneiden vor allem praktisch einen Vorteil; die Alternative hab ich gar nicht als solche gesehen gehabt zu dem Zeitpunkt. Hab jetzt ernsthaft etwas über die Frage nachdenken müssen ;) Ich denke aber, es gibt einen Vorteil: Schneidet man vertikal in einzelne Säulen, geht der Zusammenhang der Etage verloren. Beim horizontalen Schneiden beschreibt ein Polygon immer noch die Außenwand dieses Stockwerks, was insbesondere zusätzlich das mapping von Innenwänden später erlauben würde. Betrachtet man ein Gebäude, das z.B. eine Brücke bildet, dann ist die senkrechte Wand mittendrin eben nur da, wo auf einer Seite davon nichts mehr ist - das beschreibt mein Ansatz. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude-Mapping
Am 05.11.2010 22:29, schrieb Johannes Huesing: Martin Simongrenzde...@gmail.com [Fri, Nov 05, 2010 at 09:57:52PM CET]: Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen des Funkmastes, sondern um dieses allgemeine Konzept für gestückelte Gebäude, das ich mal in den Raum stellen wollte. Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso, aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. (ok) Anforderung erfüllt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OT: Haartracht mappen (was: Gebäud e-Mapping)
aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein. Wenn Ihr letztere taggen wollt, dann macht Ihr aber bitte einen eigenen Thread auf -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netbook-Anwender gesucht
ulf.lamp...@googlemail.com (Ulf Lamping) am 05.11.10: P.S: Das Hauptkriterium beim Kauf meines Netbooks war für mich die Displayauflösung von 1024*768 Pixeln. Ich wußte warum ;-) Meine Kaufkriterien waren Bezahlbakeit, lange Akkulaufzeit und Fotorucksacktauglichkeit. Alles zusammen gab es nicht mit 1024*768 oder größer. Wähle drei aus vier. Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
