Re: [Talk-de] Open Database Licence: Deutsche Über setzung
Hi, ich hab mich jetzt nicht weiter mit der Lizenz beschäftigt. Aber inwieweit hat das denn Auswirkungen auf bereits getroffene Vereinbarungen der Kooperation mit Kommunen bzw. auf künftige. schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Open Database Licence: Deutsche Über setzung
Hallo, Cornelius wrote: > Da des öfteren der Wunsch nach einer deutschen Übersetzung da war: Ich habe > mal angefangen die Lizenz zu übersetzen: Ich habe jetzt meine eigene Übersetzung fertig: http://dev.openstreetmap.org/~fred/odbl09dt.pdf (oder wahlweise auch .odt hinten). Ich will damit keinesfalls Deine Arbeit im Wiki geringschätzen oder unterminieren, aber ich hatte nun mal schon einen früheren Draft der Lizenz übersetzt *und* die Unterschiede zwichen dem früheren und aktuellen Draft auf Englisch herausgearbeitet, daher war es für mich der Weg der geringsten Arbeit, nur diese Änderungen in der deutschen Fassung nachzuziehen, anstatt eine ganz neue Übersetzung anzufangen. Ich werde im Wiki einen Link auf die o.g. Fassung setzen, aber wenn irgendjemand gern den Text aus meinem .odt ins Wiki kopieren will, hab ich da überhaupt keine Einwände. Ich habe zusätzlich zum obigen Dokument auch noch ein http://dev.openstreetmap.org/~fred/odbl09dt-changes.pdf bereitsgestellt, in dem man (anhand grüner Einfüge- und roter Löschmarkierungen) sehen kann, was sich in den 10 Monaten seit der Veröffentlichung des letzten Entwurfs geändert hat. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine Milliarde Tags
Moin, > Die gesamte Landfläche der Erde ist 510.000.000 km² daraus ergeben > sich wenn ich richtig gerechnet habe 18085 Nodes Pro m². > > Das sollte reichen :) könnte für botanisches Micromapping schon knapp werden ;-) . Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=riverbank plus name?
Am 16.02.2009 16:43, Claudius Henrichs: > Am 15.02.2009 22:51, Christoph Wagner: >> Carsten Gerlach schrieb: >>> mir ist neulich aufgefallen, daß an einigen Stellen der Flussname irgendwo >>> auf >>> dem Festland steht, z.B hier (Mapnik): >> ... >>> Ich vermute, das liegt am zusätzlichen name-Tag am waterway=riverbank. Wird >>> der Name da auf dem Flächenschwerpunkt dargestellt? Wenn ja, dann sollte der >>> Name _nur_ an das waterway=river und _nicht_ an das waterway=riverbank. >> Ja wird er. Naja... >> >>> Wie ist da die Meinung der alten Hasen? >>> >>> Grüße, Carsten >> Also das Thema war bei uns auch schon diskutiert, aber eine richtige >> Lösung haben wir auch nicht. Ich fasse mal zusammen: >> Rein inhaltlich wäre es richtig den Namen an die riverbank zu taggen, da >> sonst später keine Beziehung mehr zu dem Fluss hergestellt werden kann >> (höchstens über die Geometrie...). Meiner Meinung nach ist das ganz klar >> ein Problem des Renderers. Mapnik sollte wahrscheinlich am besten den >> Namen bei riverbank überhaupt nicht rendern. Stattdessen sollte nur der >> Name an der river linie gerendert werden. > > Wenn das alles so bekannt ist frage ich mich schon, warum es dann noch > kein Ticket dazu gibt. Wie sonst sollen der Mapnik-Stilbearbeiter davon > erfahren: > http://trac.openstreetmap.org/ticket/1599 Der Name von Riverbank-Polygonen wird jetzt nicht mehr gerendert. http://trac.openstreetmap.org/ticket/1599 Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenkarte für Aachen
Tobias Wendorff [Sun, Mar 01, 2009 at 03:45:18PM CET]: > Johannes Huesing schrieb: >> Wenn diese Punkte 40 m entfernt auf einem Track liegen, erregen schon >> 10 Höhenmeter Differenz Verdacht. > > In Dortmund-Hörde haben wir an einem Punkt 10 Höhenmeter auf 2 Meter > (Bahnstrecke) und etwas weiter an der Schnettkerbrücke das Z-fache > (Grund: Emschertal): > > http://www.arbg-dortmund.nrw.de/service/Weitere_Informationen/Aktuelles/Schnettkerbruecke.JPG Die wesentlichen Worte in meinem von Dir zitierten Satz lauteten: "auf einem Track". Du kommst zwar von der Schnettkerbrücke ins Emschertal in weniger als 40 Metern (zumindest im alten Ausbauzustand gab es da eine Treppe), aber daher sagte ich "erregen Verdacht", was heißt, dass die dort ermittelten Höhenpunkte geringeres Gewicht haben als die von einem unter der Brücke mit der S5 oder über die Brücke mit dem Rad fahrenden Mapper. >>> Unter 20 Meter Endhöhengenauigkeit wäre - meiner Meinung nach - die >>> Höhenmessung für den Popo. >> >> Für den ermittelten Wert schon (für den einzelnen Messwert nicht, auch >> wenn der ein sehr geringes Gewicht in der Höhenschätzung hätte), aber >> für Punkte weit ab von Messpunkten kann das natürlich passieren. > > Woher willst Du wissen, dass der ermittelte Punkt weitab von einem > Messpunkt einen Fehler hat? Als Statistiker gehe ich davon aus, dass jeder Messpunkt einen Fehler hat. Wissen ist das nicht, eher Modellannahme. Aber aus reichlich Erfahrung gespeist :-) -- 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] verschachtelte Multipolygone
Gerrit Lammert schrieb: > Aber im vorliegenden Fall ist die ältere Festlegung für mich die > sprachliche und demnach ist wood=Wald (genauer Gehölz) und keineswegs > Urwald. Naja, andere betonen halt das natural und folgern daraus, dass mit natural=wood nur naturbelassener Wald gemeint sein kann. > Ich würde zwar immer noch explizit natural=wood an den forest hängen, > weil es IMHO völlig verschiedene Sichtweisen sind (Landnutzung, bzw. > Beschaffenheit), aber ich sehe nirgendwo ausgeschlossen, das > Baumbestände nicht als solche getaggt werden sollen. Solange im Wiki steht, dass natural=wood einen naturbelassenen Wald meint (was im Park sicherlich nicht gegeben ist), musst du aber davon ausgehen, dass andere Leute im vertrauen auf das Wiki dir dein natural=wood wieder loeschen werden. > Also kurz: Ein Wald ist ein Wald und fertig. Ja, aber in den seltensten Faellen ist er auch im engeren Sinne "natural". Wobei da die "herrschende" Meinung nicht sonderlich konsequent ist. Beim Wasser benutzt man natural=water ja auch viel freier. > Ich denke (ausser in einer expliziten Flächennutzungskarte > vielleicht) sollte landuse so ziemlich die unterste Ebene darstellen. > Sonst müsste ja auch jeder Briefkasten, der in einem landuse=residential > steht ein layer=1 bekommen. :) Auf gleicher Ebene ist das wohl egal. Aber wenn ich mich recht entsinne, verschwinden bei Osmarenderer die Strassen, wenn du dem landuse einen hoeheren Layer verpasst. Sehr sinnvoll :-( Sinnvoller Wiese sollten die Flaechen (ob nun landuse oder natural oder was auch immer) immer unter/hinter den Linien und Punktsymbolen liegen. Ganz einfach, weil man sonst ja nichts mehr von den anderen sieht. Und wenn man dann als Mapper noch darauf achtet, dass sich verschiedene Flaechenelemente nicht ueberschneiden, dann ist man schon ein ordentliches Stueck weiter. Gruss Torsten Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] elevator=footway?
Am 26.02.2009 23:39, Johann H. Addicks: > Das kann's nicht sein, aber was ist damit gemeint? > (Auf der Innenseite der Fahrstuhltür, also "im Korb" war da auch > nochmal. Das ganze war in einem Parkhaus.) > > http://www.addicks.net/gallery/Irgendwo/P2260477 Wer die Mailingliste mitverfolgt glaubt wirklich, dass wir Deutschen Paragraphenreiter sind und alles machen, was auf uns Schilder sagen. Ich würde von der naheliegendesten Variante ausgehen: Mit dem Aufkleber wollte der Parkhausbesitzer nur anzeigen: "Leute nehmt bitte den Aufzug, auf der Autorampe werdet ihr nur überfahren." Mit StVO oder Ähnlichem hat das meiner Meinung nach nichts zu tun und ist deshalb auch nicht Tagging-relevant. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi Torsten. Torsten Leistikow wrote: > Gerrit Lammert schrieb: >> landuse=park und natural=wood schließen sich nicht aus (auch logisch, es >> sei denn man ist der Meinung in einem Park dürfe es keine Bäume geben). > > Das haben hier ein paar Leute so formuliert, ein paar fanden das gut, > ein paar nicht. Ich bin ein bisschen konservativ und finde es besser, > wenn man sich an die Vorgaben im Wiki haelt (so es denn welche zu einem > Thema gibt)und ncht einfach sein eigenes Sueppchen kocht. Da stimme ich im Prinzip zu, bin auch gegen Wildwuchs. Aber im vorliegenden Fall ist die ältere Festlegung für mich die sprachliche und demnach ist wood=Wald (genauer Gehölz) und keineswegs Urwald. Im übrigen war mit "Urwald" im Wiki nie das Zeug am Amazonas gemeint. Viel mehr steht das Wort hier wohl für einen unbewirtschafteten Wald ("ur" im Sinne von "urwüchsig"). Der nachvollziehbare Gedankengang wird gewesen sein: forest=bewirtschafteter Wald (schließt natural=wood implizit ein), wood ohne forest => unbewirtschafteter Wald. Daran soll sich ja im Prinzip auch nichts ändern. Ich würde zwar immer noch explizit natural=wood an den forest hängen, weil es IMHO völlig verschiedene Sichtweisen sind (Landnutzung, bzw. Beschaffenheit), aber ich sehe nirgendwo ausgeschlossen, das Baumbestände nicht als solche getaggt werden sollen. Man kann sicher streiten, was bewirtschafteter Wald ist und was nicht. Bäume im Park sind sicher nicht urwüchsig, aber sie dienen i.d.R. auch nicht der Holzgewinnung. Aber das ist eine andere Frage. Also kurz: Ein Wald ist ein Wald und fertig. Zu der Layer-Geschichte kann ich Dir eigentlich nur zustimmen, die würde ich hier auch nicht setzen. Da muss es eine sinnvolle Renderreihenfolge ohne layer geben, ob landuses über oder unter natural gerendert werden soll. Ich denke (ausser in einer expliziten Flächennutzungskarte vielleicht) sollte landuse so ziemlich die unterste Ebene darstellen. Sonst müsste ja auch jeder Briefkasten, der in einem landuse=residential steht ein layer=1 bekommen. :) Gerrit PS: Jetzt weiß ich auch, woher der Ausspruch "den Wald vor lauter Bäumen nicht sehen" kommt, vermutlich weil natural=tree über natural=wood gerendert wird und jemand sehr eifrig beim Tree-Mapping* war. ;-) * Nicht zu verwechseln mit der Datenstruktur ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Openstreetmap ohne Quellenangabe
Am 28. Februar 2009 23:56 schrieb Patrick Kolesa : > malenki schrieb: >> Die dort verlinkte Karte dürfte sehr wahrscheinlich mit OSM-Daten >> erstellt worden sein, ein Hinweis darauf fehlt. > > Unten links im Kartenausschnitt kann man noch ein "eetMap" erkennen. Ist > meiner Meinung nach ein Export aus den Osmarendertiles. > > Gruß > Patrick > mittlerweile ist ja ein Hinweis auf OSM auf der verlinkenden Seite und das Versprechen, dass dieser auch auf der Karte selbst demnächst angebracht werden wird. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
On Sun, 1 Mar 2009, Sven Geggus wrote: So, jetzt brauche ich nur noch die Methode, wie man GPX-Spuren darstellen kann. Das kann Openlayers. Ja, ist mir bewusst. Ich hatte ja schon ein schönes Beispiel dafür. http://geggus.net/gmaps/radtour-ausflug2008.shtml Und ich glaube, das hier war es. Jetzt habe ich fast alles in ein Skript kondensiert, was Du in den vielen Beispielen gezeigt hast. Langsam gehen mir die Herausforderungen aus. Ist aber ein richtig schöner Anfahrtsplan geworden :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key: building - Dachformen?
Am 1. März 2009 16:49 schrieb Tobias Wendorff : > Google hat es mit Sketchup optimal gelöst, finde ich. > Du weißt als Architekt selber, was für Kombinationen möglich > sind. als Architekt weiss ich, dass ich ALLES machen kann, solange es dicht ist und nicht einstürzt. Dicht "kleben" kann man heutzutage praktisch alles, nicht einstürzen ist bei fachgerechter Planung auch gegeben. >>> - Dachexposition >>> - Dachverschattung >> >> beides eher Werte, die sich berechnen lassen, wenn man das Dach in 3d drin >> hat > > Wie ich bereits schreiben. > >>> - flat (Flachdach) >> >> bis zu welcher Neigung? 5%? 5 Grad? > > Kann der normale Mapper eh nicht genau bewerten. Ansonsten > gibt es genug Fachliteratur. Das ist eine Frage der Definition, die wiederum davon abhängt, in welchem Land ich baue. Dächer ohne Neigung (also ganz flach) gibt es eigentlich nur, wenn Mist gebaut wurde. >>> - monopitch (Schleppdach) >> >> (ist eigentlich dasselbe wie ein Pultdach, als Besonderheit geht es >> ohne Übergang in die Hauptdachfläche über) > > Wie gesagt: für einen normalen Mapper oder einen Bauherren gibt es > da sicherlich einen Unterschied. meinst Du Baumeister? Bauherr ist im deutschen genau definiert und bezeichnet den Auftraggeber, also nicht unbedingt einen Sachkundigen. >>> - shed (Pultdach) >> >> ein shed ist kein Pultdach, bzw. könnte man es evtl. als Serie von >> Pultdächern begreifen. Pultdach heisst auf englisch eher monopitch >> oder pitched-roof (oder lean-to roof) > > Okay, sind sheds dann diese Fabrikhallendächer? ja, mit in fast allen Fällen Oberlichter im steilen Bereich. >> Dachformen sind sehr variantenreich, da kann man sehr weit gehen, >> wichtig wären aber m.E. in jedem Fall noch ein paar weitere Dachformen >> (wie Du schon schreibst: "z.B."): > [...] was meinst Du mit "..."? Ich würde die relevanten Möglichkeiten gleich zusammentragen, in diesem Sinne habe ich diese Auflistung als konstruktive Ergänzung Deiner Liste gesehen. > >>> Dann noch Optionen, wie dormers (Dachgauben). >> >> Fledermausgauben, Schleppgauben, ... > > Ja, dritte Google Eintrag. Muss jetzt nicht alles hier 10 mal > bezeichnet werden. ist ein komplexes Thema, Dachgauben. Die haben ja oft wieder eigene Neigungen und Ausrichtungen, ohne 3D-Software nur mit Tags sehe ich das ein bisschen schwierig, diese hier auch zu berücksichtigen (einzeichnen wird man sie in jedem Fall müssen). Nicht ganz unrelevant wären übrigens auch Balkone und Dachterrassen. > Es ist ja, wie oben beschrieben, nicht nur eine Anguck-Anwendung, > sondern auch möglich, daraus das Solarpotential zu berechnen. > Aha? Wenn man davon ausgeht, dass man die Paneele direkt auf das Dach montiert? Ansonsten kann man die ja auch: - in die Fassade integrieren - losgelöst von der Dachhaut- und Ausrichtung/Dachneigung aufmontieren Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Lizenz: Forschritte
Am 28. Februar 2009 16:01 schrieb Ulf Möller : > Sascha Silbe schrieb: > >> Gab es tatsächlich Fälle, wo die Daten _explizit_ ohne jegliche >> Einschränkungen zur Verfügung gestellt wurden? > > Ja. Die TIGER-Daten sind PD; die Strassendatenbank NRW wurde zur freien > Nutzung ohne Lizenzeinschränkungen zur Verfügung gestellt; Yahoo sagt, > dass das Abzeichnen der Bilder ihre Rechte nicht beeinträchtigt. > > Gegenbeispiele wie die Frida-Daten in Osnabrück gibt es natürlich auch. > ja, oder die AND-Daten (Niederlande und Indien) oder in Italien sämtliche Verwaltungsgrenzen der höheren Ebenen (ab Kommune) und diverse andere GIS-Spenden (Schweiz, Österreich, Frankreich, Italien, etc.) sowohl von privaten Firmen als auch von der öffentlichen Hand. Die staatl. US-Daten sind PD, aber sehr viele der anderen Spender haben das erstmal gemacht in der Gewissheit, dass wir ein CC-BY-SA-Projekt sind. Diese müsste man auf jeden Fall alle anfragen. Für diese Spenden wäre es sicher auch nicht schlecht, eine tabellarische Auflistung zu haben mit den Angaben, ob sie der Lizenzänderung zustimmen sowie wieviele Nodes und Ways davon jeweils betroffen sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key: building - Dachformen?
Martin Koppenhoefer schrieb: > eher uninteressant da ableitbar Wie ich bereits schreiben. >> - Dachform > > komplexes Thema. Wie willst Du beispielsweise die Ausrichtung angeben? > Die Ausrichtung ist sehr wichtig, weil wenn sie nicht stimmt, das > ganze Dach schlechter ist als gar nicht drin. Da ich in der Materie drin stecke, darfst Du mir die Frage nicht stellen. Du solltest eher fragen, wie "Normalmapper" es notieren würden. Google hat es mit Sketchup optimal gelöst, finde ich. >> - Dachneigung > > gehört das nicht zur Form? Zumindest um überhaupt die Form > einigermaßen interpretieren zu können ist die Neigung auf jeden Fall > erforderlich Du weißt als Architekt selber, was für Kombinationen möglich sind. >> - Dachexposition >> - Dachverschattung > beides eher Werte, die sich berechnen lassen, wenn man das Dach in 3d drin hat Wie ich bereits schreiben. >> - flat (Flachdach) > bis zu welcher Neigung? 5%? 5 Grad? Kann der normale Mapper eh nicht genau bewerten. Ansonsten gibt es genug Fachliteratur. >> - monopitch (Schleppdach) > (ist eigentlich dasselbe wie ein Pultdach, als Besonderheit geht es > ohne Übergang in die Hauptdachfläche über) Wie gesagt: für einen normalen Mapper oder einen Bauherren gibt es da sicherlich einen Unterschied. >> - shed (Pultdach) > ein shed ist kein Pultdach, bzw. könnte man es evtl. als Serie von > Pultdächern begreifen. Pultdach heisst auf englisch eher monopitch > oder pitched-roof (oder lean-to roof) Okay, sind sheds dann diese Fabrikhallendächer? > Dachformen sind sehr variantenreich, da kann man sehr weit gehen, > wichtig wären aber m.E. in jedem Fall noch ein paar weitere Dachformen > (wie Du schon schreibst: "z.B."): [...] >> Dann noch Optionen, wie dormers (Dachgauben). > Fledermausgauben, Schleppgauben, ... Ja, dritte Google Eintrag. Muss jetzt nicht alles hier 10 mal bezeichnet werden. >> Auch im Hinblick auf die Projekte der Uni Bonn sollte das >> immer wichtiger für uns werden. > > ja, allgemein für 3D sehr "nice to have". Es ist ja, wie oben beschrieben, nicht nur eine Anguck-Anwendung, sondern auch möglich, daraus das Solarpotential zu berechnen. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key: building - Dachformen?
2009/3/1 Tobias Wendorff : > Tobias Knerr schrieb: >> Durch die sich abzeichnenden 3D-Verwendungen könnte inzwischen der >> Antrieb für so was da sein, den es zur Erstellungszeit des genannten >> Proposals (2006) noch nicht gab. > > Allerdings fehlen noch geeignete Editoren. Google hat ja damals > Sketchup gekauft, mit dem man sehr gut und einfach Gebäude > einzeichnen kann. > > Naja, das kommt ja bei uns vielleicht auch noch. > wenn Du das hier problemlos einzeichnen kannst: http://upload.wikimedia.org/wikipedia/commons/5/51/Guggenheimbilbao.jpg sollte auch alles andere machbar sein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key: building - Dachformen?
Tobias Knerr schrieb: > Durch die sich abzeichnenden 3D-Verwendungen könnte inzwischen der > Antrieb für so was da sein, den es zur Erstellungszeit des genannten > Proposals (2006) noch nicht gab. Allerdings fehlen noch geeignete Editoren. Google hat ja damals Sketchup gekauft, mit dem man sehr gut und einfach Gebäude einzeichnen kann. Naja, das kommt ja bei uns vielleicht auch noch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key: building - Dachformen?
Am 1. März 2009 16:10 schrieb Tobias Wendorff : > Hallo Community, > > aus älterem Projekt-Bestand zur Errechnung von Solarpotential > in Wohnbebauung habe ich noch Daten, die ich für OpenStreetMap > verwenden könnte. > > Hinterlegt sind: > - Dachfläche (teilw. Modulfläche) eher uninteressant da ableitbar > - Dachform komplexes Thema. Wie willst Du beispielsweise die Ausrichtung angeben? Die Ausrichtung ist sehr wichtig, weil wenn sie nicht stimmt, das ganze Dach schlechter ist als gar nicht drin. > - Dachneigung gehört das nicht zur Form? Zumindest um überhaupt die Form einigermaßen interpretieren zu können ist die Neigung auf jeden Fall erforderlich > - Dachexposition > - Dachverschattung beides eher Werte, die sich berechnen lassen, wenn man das Dach in 3d drin hat > Viele Teile lassen sich aus den anderen Berechnen, wobei für > die meisten Mapper eh nur die Dachform interessant wäre. naja, m.E. Form und Neigung, eigentlich auch First- und Traufhöhe, Dachüberstand > Gibt es schon einen "roof"-Key? Attribute wären z.B.: das ist m.E. als building attributes vorgeschlagen, gut wäre wohl, das wie von Dir impliziert unter einem Subtag zu subsummieren: building:roof > - flat (Flachdach) bis zu welcher Neigung? 5%? 5 Grad? > - gable (Satteldach) > - hip (Walmdach) > - mansard (Mansardendach) > - monopitch (Schleppdach) (ist eigentlich dasselbe wie ein Pultdach, als Besonderheit geht es ohne Übergang in die Hauptdachfläche über) > - shed (Pultdach) ein shed ist kein Pultdach, bzw. könnte man es evtl. als Serie von Pultdächern begreifen. Pultdach heisst auf englisch eher monopitch oder pitched-roof (oder lean-to roof) Dachformen sind sehr variantenreich, da kann man sehr weit gehen, wichtig wären aber m.E. in jedem Fall noch ein paar weitere Dachformen (wie Du schon schreibst: "z.B."): Krüppelwalmdach Tonnendach Kuppel Zeltdach/Pyramidendach Zwiebelhaube/Zwiebelturm (bzw. allgemein Hauben) Shed-Dach Kegeldach Berliner Dach sowie diverse ausländische Dachformen... > Dann noch Optionen, wie dormers (Dachgauben). Fledermausgauben, Schleppgauben, ... sollten die dann einzeln gezeichnet werden? > Auch im Hinblick auf die Projekte der Uni Bonn sollte das > immer wichtiger für uns werden. ja, allgemein für 3D sehr "nice to have". Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine Milliarde Tags
Jochen Topf wrote: >> 64-Bit unsigned sollte etwas länger reichen: 18446744073709551615 > > Die MySQL nimmt 64Bit Ints. Aber nicht alle Software, die die Daten > nutzt macht das auch... Signed int? Das wäre dann 9223372036854775807 mögliche Nodes. Die gesamte Landfläche der Erde ist 510.000.000 km² daraus ergeben sich wenn ich richtig gerechnet habe 18085 Nodes Pro m². Das sollte reichen :) Gruss Sven -- "I'm a bastard, and proud of it" (Linus Torvalds, Wednesday Sep 6, 2000) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key: building - Dachformen?
Tobias Wendorff schrieb: > Gibt es schon einen "roof"-Key? Attribute wären z.B.: > > - flat (Flachdach) > - gable (Satteldach) > - hip (Walmdach) > - mansard (Mansardendach) > - monopitch (Schleppdach) > - shed (Pultdach) > > Dann noch Optionen, wie dormers (Dachgauben). Es gibt das ältere Proposal zu "Gebäudeattributen": http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes Nicht so verbreitet laut Tagwatch und auch nicht unbedingt eine ideale Lösung (soweit ich sehe, vermischt es Material und Form). Vielleicht kannst du ja ein paar Ideen rausfischen und zusammen mit deinen Vorschlägen ins Wiki packen? Durch die sich abzeichnenden 3D-Verwendungen könnte inzwischen der Antrieb für so was da sein, den es zur Erstellungszeit des genannten Proposals (2006) noch nicht gab. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
Jochen Topf wrote: > Bei http://tools.geofabrik.de/mc/ muss ich das auch machen, wenn > man zwischen Google- und OSM-Layern wechselt. Huch? Ich dachte Google und OSM würden die selbe Projektion verwenden? Sven -- "The American news-media is no longer a news source; it is a cheerleading squad." (unknown source) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
Dirk Stöcker wrote: > So, jetzt brauche ich nur noch die Methode, wie man GPX-Spuren darstellen > kann. Das kann Openlayers. http://geggus.net/gmaps/radtour-ausflug2008.shtml Gruss Sven -- "Software is like sex; it's better when it's free" (Linus Torvalds) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Gerrit Lammert schrieb: > landuse=park und natural=wood schließen sich nicht aus (auch logisch, es > sei denn man ist der Meinung in einem Park dürfe es keine Bäume geben). Das haben hier ein paar Leute so formuliert, ein paar fanden das gut, ein paar nicht. Ich bin ein bisschen konservativ und finde es besser, wenn man sich an die Vorgaben im Wiki haelt (so es denn welche zu einem Thema gibt)und ncht einfach sein eigenes Sueppchen kocht. D.h. wenn man die Bedeutung eines etablieretn Tags aendern will (das gilt sowohl fuer natural=wood als auch fuer das layer-Tag), dann sollte man am besten dafuer den Approval-Prozess anschmeissen, da bestimmt nicht alle fuer diese Aenderung sind. Auf alle Faelle sollte man aber die Beschreibung im Wiki anpassen. OSM ist ja gewollt sehr frei gehalten und ich habe auch nichts dagegen, wenn man seine eigenen Tags definiert. Aber bei der Bedeutung von bereits etabliereten Tags sollte man doch lieber zurueckhaltend sein, denn sonst weiss ja wirklich keiner mehr, was die Sachen in der Datenbank sollen. Anstatt das Layer-Tag umzudeuten (es ist von Anfang an als physikalisches Uebereinander definiert worden), kann man ja einfach ein neues Tag render_layer einfuehren. Alternativ muessten wir naemlich sonst auch ein neues Tag fuer die physikalische Anordnung erfinden. Und statt natural=wood umzudeuten kann man ja auch ein vegetation=wood einfuehren mit der gewuenschten Bedeutung. Das liesse sich dann auch gleich auf vegetation=gras und vegetation=flowers und aehnliche Sachen erweitern und koennte als Ergaenzung problemlos neben den bisherigen landuse-Tags existieren. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ORS - Fußgänger-Routing über Pl ätze
Hallo Community, ich frage mal hier, um die ORS-Leute nicht von der Entwicklung abzuhalten :-) Ist generell schon ein Routing über Plätze möglich, auf denen keine Wege vorhanden, sondern uneingeschränktes Bewegen für Fußgänger möglich ist? Wichtige Plätze hier in Dortmund werden "umgangen", obwohl man einfach quer drüber laufen kann und soll. Getaggt ist z.B. der Hansaplatz als "highway: pedestrian". Auch scheinen die Verbindungen der angrenzenden Straßen korrekt angebracht worden zu sein. Habt Ihr ähnliche Erfahrungen gemacht? Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] key: building - Dachformen?
Hallo Community, aus älterem Projekt-Bestand zur Errechnung von Solarpotential in Wohnbebauung habe ich noch Daten, die ich für OpenStreetMap verwenden könnte. Hinterlegt sind: - Dachfläche (teilw. Modulfläche) - Dachform - Dachneigung - Dachexposition - Dachverschattung Viele Teile lassen sich aus den anderen Berechnen, wobei für die meisten Mapper eh nur die Dachform interessant wäre. Gibt es schon einen "roof"-Key? Attribute wären z.B.: - flat (Flachdach) - gable (Satteldach) - hip (Walmdach) - mansard (Mansardendach) - monopitch (Schleppdach) - shed (Pultdach) Dann noch Optionen, wie dormers (Dachgauben). Auch im Hinblick auf die Projekte der Uni Bonn sollte das immer wichtiger für uns werden. Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aachen - Komplettdownload
Johannes Huesing schrieb: >> http://www.file-upload.net/download-1481299/GPX_Aachen.zip.html >> > Ich weiß ich war nciht angesprochen, aber er macht 'nen 404 hier. Habe es auf den Uni-Server gelegt. "Lebt" für 1 Woche ab jetzt: http://depot.tu-dortmund.de/get/wemq8z ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenkarte für Aachen
Johannes Huesing schrieb: > Wenn diese Punkte 40 m entfernt auf einem Track liegen, erregen schon > 10 Höhenmeter Differenz Verdacht. In Dortmund-Hörde haben wir an einem Punkt 10 Höhenmeter auf 2 Meter (Bahnstrecke) und etwas weiter an der Schnettkerbrücke das Z-fache (Grund: Emschertal): http://www.arbg-dortmund.nrw.de/service/Weitere_Informationen/Aktuelles/Schnettkerbruecke.JPG >> Unter 20 Meter Endhöhengenauigkeit wäre - meiner Meinung nach - die >> Höhenmessung für den Popo. > > Für den ermittelten Wert schon (für den einzelnen Messwert nicht, auch > wenn der ein sehr geringes Gewicht in der Höhenschätzung hätte), aber > für Punkte weit ab von Messpunkten kann das natürlich passieren. Woher willst Du wissen, dass der ermittelte Punkt weitab von einem Messpunkt einen Fehler hat? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
On Sun, 1 Mar 2009, Sven Geggus wrote: Dirk Stöcker wrote: Die Frage warum ich für alle Layer gleiche Projektionen brauche bleibt Deine darstellbare Fläche hat ja eine fixe Begrenzung x1,x2,y1,y2 Naja, für meine Anwendung brauche ich keine fixe Fenstergröße. Das Zentrum ist wichtiger :-) So, jetzt brauche ich nur noch die Methode, wie man GPX-Spuren darstellen kann. Ich bin mir sicher, dass ich einen Link auf ein gutes Beispiel hatte, nur wo der wieder hin ist ... Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
Dirk Stöcker wrote: > Die Frage warum ich für alle Layer gleiche Projektionen brauche bleibt Deine darstellbare Fläche hat ja eine fixe Begrenzung x1,x2,y1,y2 Wenn Du nun eine Andere Projektion wählt, sagen wir mal zum Beispiel lat/long WGS84, was ja eine völlig verzerrte Darstellung ist, dann kannst Du ja die selbe Bounding-Box in dieser anderen Projektion gar nicht wirklich darstellen, wenn man die Fenstergröße mal als Fix ansieht. Natürlich könnte man die Karte verzerrt darstellen und WMS kann das im Prinzip. Ob man das haben möchte ist ein ganz andere Thema. Sven -- "The American news-media is no longer a news source; it is a cheerleading squad." (unknown source) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine Milliarde Tags
On Sun, Mar 01, 2009 at 11:30:30AM +, Sven Geggus wrote: > Jochen Topf wrote: > > > Die OSM-Datenbank enthält jetzt über eine Milliarde Tags an Nodes, Ways > > und Relations zusammen. Herzlichen Glückwunsch! > > Welcher Datentyp wird denn für die OSM-ID verwendet? Müssen wir uns > da Sorgen machen? > > 32-Bit unsigned sind nämlich "nur" 4294967295 > Die genannte Milliarde ist da schon erstaunlich nahe dran: 10 Eine Milliarde sind die Tags, die haben keine IDs. Nodes gibts "nur" ca. 300 Mio. :-) Allerdings werden gelöschte IDs nicht wieder vergeben sodass wir 20% oder so Overhead haben. Ein bischen reicht das aber noch mit 32 bit, aber nicht ewig. > 64-Bit unsigned sollte etwas länger reichen: 18446744073709551615 Die MySQL nimmt 64Bit Ints. Aber nicht alle Software, die die Daten nutzt macht das auch... Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
On Sun, Mar 01, 2009 at 12:55:58PM +0100, Dirk Stöcker wrote: > On Sun, 1 Mar 2009, Dirk Stöcker wrote: > >>> Wichtig zu wissen ist, dass Openlayers selbst nicht umprojizieren >>> kann, d.h. Dein WMS muss Simple Mercator (Google Projektion >>> EPSG:900913) anbieten, was die meisten WMS-Server eher nicht machen. >> >> Das hilft nicht. > > Doch. Der Code hat geholfen. Danke. > > Die Frage warum ich für alle Layer gleiche Projektionen brauche bleibt > aber. Also wenn Du sie überlagern willst, ist ja klar. Und dafür ist Open Layers halt ausgelegt. Es kann nicht für Dich umrechnen kann, wenn Du die Layer wechselst. Du kannst aber natürlich die Layer-Wechselei komplett selbst machen und immer hin- und herrechnen. Das ist etwas mühsam geht aber. Bei http://tools.geofabrik.de/mc/ muss ich das auch machen, wenn man zwischen Google- und OSM-Layern wechselt. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi Torsten. Torsten Leistikow wrote: > Bei dem Beispiel mit dem Park sehe ich das Problem, dass sich in meinen > Augen Wald und Park eigentlich ausschliessen. Fuer Wald haben wir zwei > allg. akzeptierte Tags: landuse=forest steht fuer forstwirtschaftlich > genutzte Flaechen und natural=wood steht fuer naturbelassenen Urwald. > Beides gehoert eigentlich nicht zu einem Park. Stattdessen sehe ich das > eigentlich eher so, dass das Tag leisure=park bereits beinhaltet, dass > da Baeume stehen. Das war hier letztens mal Thema: Kurzfassung: landuse=forest und landuse=park schließen sich aus (logisch). landuse=park und natural=wood schließen sich nicht aus (auch logisch, es sei denn man ist der Meinung in einem Park dürfe es keine Bäume geben). Ergebnis könnte dann etwa so aussehen: http://www.openstreetmap.org/?lat=52.26866&lon=10.55489&zoom=16&layers=B000FTF natural=wood als Synonym für Urwald zu benutzen ist quatsch. Richtig ist, das das meiste landuse=forest auch natural=wood ist. In Deutschland treten, außer in Schutzgebieten, vermutlich beide tags meistens parallel auf... In einem Park müssen IMHO überhaupt keine Bäume stehen. Manchmal gibt es große, alte, einzelne Bäume, die würde ich aber nicht mit natural=wood taggen (sondern natural=tree auf node). Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Dimitri Junker [Sun, Mar 01, 2009 at 03:22:50AM CET]: > Hallo, > > > >Wenn jede Höhenlinie ihr eigenes Konfidenzintervall mitbringt, wird es > >natürlich sehr fein. Nicht dass man das in einer Straßenkarte > >dargestellt haben möchte :-) > > > Wie soll ich das machen? 1. Wie bestimme ich die Höhenlinie rechnerisch? 2. > Wie dann das Konfidenzintervall? Höhenlinien mit Konfidenzintervallen bezüglich ihrer Lage sind sicherlich Unfug, da sie in flachen Gegenden sehr ungenau werden. Aber jeden Höhenpunkt in Deinem 1024x1024-Gitter möchte man schon mit einer Präzisionsangabe versehen haben. > Spätestens nach dem Auffüllen der Lücken > sind die Fehler doch sehr geschätzt. Sicher sind die Fehler geschätzt, wenn ich sie genau kennen würde, könnte ich sie vom Messwert abziehen und bin fertig. -- 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] Data Layer on osm.org and landuse areas
Hallo, Frederik Ramm schrieb: > does anyone have a good trick how to select individual roads on the > openstreetmap.org data layer when the whole village is covered by a > freaking "landuse" polygon? I can only ever select the polygon ;-( Klick "Manualy select a different area". Ziehe einen Auswahlrahmen auf, der die Poligongrenze NICHT schneidet. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
On Sun, 1 Mar 2009, Dirk Stöcker wrote: Wichtig zu wissen ist, dass Openlayers selbst nicht umprojizieren kann, d.h. Dein WMS muss Simple Mercator (Google Projektion EPSG:900913) anbieten, was die meisten WMS-Server eher nicht machen. Das hilft nicht. Doch. Der Code hat geholfen. Danke. Die Frage warum ich für alle Layer gleiche Projektionen brauche bleibt aber. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
On Sun, 1 Mar 2009, Sven Geggus wrote: Dirk Stöcker wrote: hat jemand ein funktionierendes Beispiel, wie man WMS in OpenLayers einbindet? Das geht sehr einfach: http://geggus.net/gmaps/myfsmap.html Wichtig zu wissen ist, dass Openlayers selbst nicht umprojizieren kann, d.h. Dein WMS muss Simple Mercator (Google Projektion EPSG:900913) anbieten, was die meisten WMS-Server eher nicht machen. Das hilft nicht. Wenn EPSG:900913 unterstützt würde, dann würde es wahrscheinlich funktionieren. Warum muss es denn EPSG:900913 sein? Ich habe die Layer doch alle separat. Die müssen doch überhaupt nicht die gleiche Projektion nutzen. Bei Overlays würde ich es ja verstehen, aber bei separaten Layern? Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine Milliarde Tags
Jochen Topf wrote: > Die OSM-Datenbank enthält jetzt über eine Milliarde Tags an Nodes, Ways > und Relations zusammen. Herzlichen Glückwunsch! Welcher Datentyp wird denn für die OSM-ID verwendet? Müssen wir uns da Sorgen machen? 32-Bit unsigned sind nämlich "nur" 4294967295 Die genannte Milliarde ist da schon erstaunlich nahe dran: 10 64-Bit unsigned sollte etwas länger reichen: 18446744073709551615 Gruss Sven -- /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */(taken from /usr/src/linux/lib/vsprintf.c) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
Dirk Stöcker wrote: > hat jemand ein funktionierendes Beispiel, wie man WMS in OpenLayers > einbindet? Das geht sehr einfach: http://geggus.net/gmaps/myfsmap.html Wichtig zu wissen ist, dass Openlayers selbst nicht umprojizieren kann, d.h. Dein WMS muss Simple Mercator (Google Projektion EPSG:900913) anbieten, was die meisten WMS-Server eher nicht machen. Bei obiger URL ist der WMS-Layer leider proprietär, sodass ich ihn mit username und passwort schützen muss. Das dahinterliegende geoTiff für den Mapserver muss nun entweder direkt in EPSG:900913 vorliegen oder der Mapserver muss das umprojizieren. Beides funktioniert. Gruss Sven -- "Thinking of using NT for your critical apps? Isn't there enough suffering in the world?" (Advertisement of Sun Microsystems in Wall Street Journal) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhennetz/Höhendatenbank
Hallo, >Wenn jede Höhenlinie ihr eigenes Konfidenzintervall mitbringt, wird es >natürlich sehr fein. Nicht dass man das in einer Straßenkarte >dargestellt haben möchte :-) Wie soll ich das machen? 1. Wie bestimme ich die Höhenlinie rechnerisch? 2. Wie dann das Konfidenzintervall? Spätestens nach dem Auffüllen der Lücken sind die Fehler doch sehr geschätzt. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
On Sun, 1 Mar 2009, Frederik Ramm wrote: hat jemand ein funktionierendes Beispiel, wie man WMS in OpenLayers einbindet? wms.geofabrik.de Hmm, nach vielen Probieren bekomme ich WMS hin. Sobald ich aber einen OSM-Layer als Alternative anbieten will, schaltet der mir für WMS auf EPSG:900913 unabhängig davon was ich will. Binde ich erst WMS und dann einen OSM-Layer ein, dann geht OSM nicht. Irgendwas ist an den OSM-OpenLayers-Skripten noch falsch. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Data Layer on osm.org and landuse areas
Frederik Ramm schrieb: > does anyone have a good trick how to select individual roads on the > openstreetmap.org data layer when the whole village is covered by a > freaking "landuse" polygon? I can only ever select the polygon ;-( Das Problem wurde irgendwann im Forum diskutiert. Manche lösen das Problem offenbar indem sie die landuse areas einfach loeschen. Ich halte das zwar nicht für gut, aber immerhin kann man die Gebiete später wiederherstellen. Grungelborz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Data Layer on osm.org and landuse areas
2009/3/1 Frederik Ramm : > Hi, > > does anyone have a good trick how to select individual roads on the > openstreetmap.org data layer when the whole village is covered by a > freaking "landuse" polygon? I can only ever select the polygon ;-( What I do is zooming in until the area is bigger than the map view, so it won't be downloaded. Now you can select individual Objects in the area - but it's still a pain in the ass. ;-) -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Data Layer on osm.org and landuse areas
Frederik Ramm schrieb: > Hi, > > does anyone have a good trick how to select individual roads on the > openstreetmap.org data layer when the whole village is covered by a > freaking "landuse" polygon? I can only ever select the polygon ;-( > Falsche Liste? ;-) Hab das selbe festgestellt, manchmal kann ich irgendwie die Straße auswählen, manchmal aber auch nur das polygon. Alternativ kann man über die object list gehen, ist aber nur eine Notlösung. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Eine Milliarde Tags
Hi! Die OSM-Datenbank enthält jetzt über eine Milliarde Tags an Nodes, Ways und Relations zusammen. Herzlichen Glückwunsch! Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Data Layer on osm.org and landuse areas
Hi, does anyone have a good trick how to select individual roads on the openstreetmap.org data layer when the whole village is covered by a freaking "landuse" polygon? I can only ever select the polygon ;-( Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers WMS
Hi, Dirk Stöcker wrote: > hat jemand ein funktionierendes Beispiel, wie man WMS in OpenLayers > einbindet? wms.geofabrik.de Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OpenLayers WMS
Hallo, hat jemand ein funktionierendes Beispiel, wie man WMS in OpenLayers einbindet? Mein Versuch (im Anhang) lädt leider nur schwarze Kacheln (auf Luftbild-Ebene umschalten). Ciao -- http://www.dstoecker.eu/ (PGP key available)Title: Test Mit freundlicher Unterstützung von openstreetmap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
On Sun, 1 Mar 2009, Torsten Leistikow wrote: Eigenschaft in einem speziellen Fall vorangig dargestellt werden sollte. Dafuer muesste man dann aber Renderer-Kontroll-Tags einfuehren und nicht die Daten kuenstlich verbiegen, wie z.B. durch falsches Anbringen von Layer-Tags. Stellt Dir vor. Das Layer-Tag ist genau dieses Render-Kontrolltag. Es sagt nämlich dass Objekt x oberhalb/unterhalb von Objekt y ist. Das manche dort unbedingt physikalische Eigenschaften hineininterpretieren wollen ändert daran nichts. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de