[Talk-de] Hausnummern
...und noch ein Mecker ;) Da ich mich grade ein wenig in die Erfassung von Hausnummern verbissen habe, irritiert mich mal wieder die Darstellung derselben. Mancherorts sieht man vor lauter Hausnummerklecksen nichts anderes mehr (Altstadt MG z.B. - sorry, hab grad keinen Link). War da nicht mal eine Änderung geplant? Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG die 3.
Gary68 schrieb: nach einigen guten tipps nun mal was richtiges zum vorzeigen. inkscape und ff zeigen nun alle straßen beschriftet. Opera im übrigen auch ;-) Danke für das nette Tool, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
BroadwayLamb schrieb: Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. da stimme ich dir voll und ganz zu. am besten würde mir aber gefallen, wenn die Hausnummern immer verschoben würden. es gibt so viele Objekte die diese überlagern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fitness-Center
Hallo! Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Nach meiner bescheidenen Meinung würde Darstellung Was geschieht eigentlich mit solchen und ähnlichen *Wünschen an die Renderer*? Wer ist das eigentlich: die Renderer? Wer sind die Macher, die diese gestalten? Wie ist der Kontakt zwischen diesen und dem Rest der OSM-Welt geregelt? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG ???
On Fri, Jan 23, 2009 at 07:13:03PM +0100, Tim 'avatar' Bartel wrote: Subject: Re: [Talk-de] SVG ??? Hi, Am 23. Januar 2009 18:37 schrieb Gary68 g...@gary68.de: WIE BEKOMME ICH DAS UNTER LINUX ZU SEHEN? Inkscape, gwenview, Gimp, ... (welches svg-faehige Linux-Programm kann es *nicht*?) Es gibt keine vernuenftige vollstaendig SVG implementation unter Linux. Inkscape ist as-good-as-it-gets ... Sobald man Text on a Path macht ist bei den meisten svg engines vorbei. Das habe ich mir fuer ti...@home mal angesehen weil inkscape einfach ein raeudiges stueck software ist was auch mal schnell 4-10GB (Ja Gigabyte) zum rendern braucht .. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
Tim 'avatar' Bartel schrieb: Ebenso werden die vielerorts erfassten sub_stations gar nicht (mehr?) gerendert. Dumme Frage: sub_stations werden momentan aber weder von Mapnik noch von Osmarender gerendert, oder? (Mir war auch gar nicht aufgefallen, dass die vorher mal gerendert wurden - ich bin ein großer Freund von power-tagging). Mapnik rendert die schon lange - zumindest als Area. Bei Osmarender bin ich mir nicht sicher. Ich weiß nur, daß die Darstellung der power lines bzw. towers dort auch schon mal besser war. Hier mal ein Link: http://www.openstreetmap.org/?lat=51.21249lon=6.45888zoom=17layers=B000FTFT http://www.openstreetmap.org/?lat=51.21249lon=6.45888zoom=17layers=B000FTFT Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Am 24. Januar 2009 02:25 schrieb Karl Eichwalder k...@gnu.franken.de: Das ist nicht das Problem des Mappers, sondern des Routers. Nein, das ist eine nicht rückwärtskompatible neuerung. Besser sollte man mappen, um alte anwendungen nicht zu beeinträchtigen: highway=construction contruction=motorway In Bau befindliche Teiche bekommen hier auch ein contruction=yes an das natural=water. ein natural=construction wäre auch ziemlich sinnfrei. Nein, nicht unbedingt. Wenn dir das alles gar nicht gefällt, dann verwende einen pseudo-namespace: contruction:natual=water Mal im Ernst, so bescheuert, wie ich Garrys mapping-für-Garmin-Aktionen(siehe Inseln und Wald) auch finde; construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zurückgebaut trifft die Sache einfach besser. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Ein Renderer könnte zum Beispiel alles, was diesen Zusatztag hat, halbtransparent, rot-weiß schraffiert oder mit dem Symbol eines Bier trinkenden Bauarbeiters versehen zeichnen, ohne sich um die Art des Objekts zu kümmern. Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] riverbank und wildbach
Hallo Hermann, im frühjahr für mehrere wochen und im sommer nach starkregen für ein paar stunden führen sie um grössenordnungen mehr wasser als die restliche zeit. _Küstenlinie_ Vergleichbares gibt es auch in Küstengewässern mit starker Tide, oder in flachen Küstengewässern: bei Flut sind sie unter Wasser, bei Ebbe fallen sie trocken. Dort werden (oder sollte) *zwei Küstenlinien* eingetragen: Küstenlinie LAT (bei niedrigst möglichem Wasserstand) http://wiki.openstreetmap.org/wiki/de:Lowest_Astronomical_Tide Küstenlinie NHN (Normalhöhennull) http://de.wikipedia.org/wiki/Normalhöhennull Das Gebiet dazwischen nennt man trockenfallend. Es sollte als blassgrüne Fläche gerendert werden. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Andreas Labres schrieb: Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Es gibt ein leisure=sports_centre. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Nein, das ist eine nicht rückwärtskompatible neuerung. Besser sollte man mappen, um alte anwendungen nicht zu beeinträchtigen: highway=construction contruction=motorway Ich finde, im jetzigen Zustand der Unordnung Rückwärtskompatibilität einzuführen äußerst kontraproduktiv. Das ist etwas, was man in vielen Jahren machen kann, wenn die ganzen Unstimmigkeiten im Tagging ausgemerzt sind. Ich will gar nicht dran denken, wie das jetzt ausschauen würde, wenn die gleiche nichtskalierende Methode auch bei oneway und access etc. verwendet worden wäre. Grüße, Marc 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] Hausnummern - Renderer
Markus schrieb: Nach meiner bescheidenen Meinung würde Darstellung Was geschieht eigentlich mit solchen und ähnlichen *Wünschen an die Renderer*? meist arbeitet die einer der Renderer in das style-file des osmarenders ein Wer ist das eigentlich: die Renderer? jeder der einen svn Zugang hat und sich da eingearbeitet hat. bin leider nur einer der ersteren ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Torsten Leistikow schrieb: Es gibt ein leisure=sports_centre. währe da nicht sport=sports_centre korrekter? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Hallo Sebastian, http://wiki.openstreetmap.org/wiki/Proposed_features/More_access_keys_and_values das ist nicht logisch: Entweder es ist nach Benutzern geordnet: highway=path + agricultural=yes + foot=yes Oder es ist in Access als Gruppe zusammengefasst: highway=path + access=agricultural + acess=foot aber bitte nicht beides oder gar durcheinander. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
Tim 'avatar' Bartel schrieb: Alles klar - ich habe die bisher nie als Area, sondern als Point gemappt. Als sub_station's mappe ich die Dinger, die größer sind als die hier: http://www.addicks.net/gallery/strom/DSCF0807_001 Also sowas hier und kleinere: http://www.addicks.net/gallery/strom/P3170111 In a residential area, these are typically little buildings the size of a garden shed, with about a metre perimeter of land around them, and a fence or wall with 'warning high voltage' signage. Die sind in der Regel zu klein um sie als Area zu erfassen. Oops, da gab es dann wohl eine Änderung beim Tagging, die mir entgangen ist. Aus allen meinen sub_stations sind dann neuerdings wohl stations geworden - also so was wie das hier: http://wiki.openstreetmap.org/wiki/Image:800px-Transmissionsubstation.jpg Ob diese Unterscheidung allerdings dem tatsächlichen englischen Sprachgebrauch entspricht, wage ich zu bezweifeln... Ein Umspannwerk im Hochspannungsbereich ist nach meiner Meinung eine substation. Die Schaltkästen aus deinen Beispielen - coole Graffiti übrigens ;) - habe ich bisher überhaupt nicht erfasst und würde das auch eher als switchbox / switch unit oder so bezeichnen. Jedenfalls sind die definitiv zu klein, um sie als area zu erfassen, da stimme ich dir zu ;) Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
BroadwayLamb broadwayl...@gmx.net wrote: seit einer der letzten ?nderungen f?llt mir auf, da? power=line im osmarender-layer nach meiner Meinung viel zu prominent dargestellt wird. Ansichtssache ;-) Ich wollte man_made=pipeline einbauen in Osmarender und suchte power als Muster (transportiert ja auch Energie... also warum nicht daran orientieren...) und ... ... suchte erstmal vergebens, weil die sich auf meinem Laptop-LCD kaum von so manchen Hintergruenden hier in der Gegend abhoben. Selbst vom Standardhintergund hoben sie sich kaum ab. Daher habe ich ein wenig experimentiert und das Grau etwas abgedunkelt und ihnen fuer dunkle Hinteruende eine helle Unterlage verpasst. Und nun sieht man sie auch, wenn sie ueber landuse=farm oder die pipelines durch den Wald laufen, wo ich ueber sie beim mappen von Waldwegen stolperte... Pipeline-Bsp.: http://www.informationfreeway.org/?lat=49.08lon=8.424zoom=16 Oel und Gas kreuzen sich dort. Wenn man nach link an den Waldrand geht und dann aufwaerts, findet man auch die powers, die ich kaum sah wegen div. dunkler Hintergruende... Die eigentlichen Landmarken, die riesigen Strommasten jedoch sind kaum erkennbar. Ebenso werden die vielerorts erfassten sub_stations gar nicht (mehr?) gerendert. Stimmt, um die tower wollt eich mich noch kuemmern, verschob ich erstmal, weil die woanders definiert wurden als im style selbst... Habe ich eben nachgeholt, Wenn mit frischen styles gerendert wird, sollten sie das gleiche Grau haben wie die Leitung: #808080 derzeit. sub_station scheinen in den styles nicht drin zu sein. Da waere ich aber unschuldig, falls die frueher drin gewesen sein sollten... Falls ich mit dieser Meinung nicht alleine dastehen sollte, dann w?re es nett, wenn das ein wenig angepasst werden k?nnte. Man muss ja nicht alles von Mapnik kopieren, aber da ist es perfekt gel?st Ohja, da sieht man sie noch besser, weil noch dunkler, soll ich? ;-) und nicht strichliert, also eigentlich noch prominenter... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Josias schrieb: Torsten Leistikow schrieb: Es gibt ein leisure=sports_centre. währe da nicht sport=sports_centre korrekter? Wenn man der bisherigen (nicht ganz trivialen :-) Logik folgt ist das schon ok. sport=xy gibt nur die jeweilige(n) Sportart(en) an. leisure=stadium, golf_course, pitch, ... gibt dann die jeweiligen *Sportstätten* an Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Dimitri Junker o...@dimitri-junker.de wrote: K?nnte man ihnen aber doch beibringen oder? Das sind doch nur Geraden oder kommen da auch Beziers vor? Bei Geraden sehe ich da nicht das gro?e Problem, Beziers sind etwas aufw?ndiger, im Notfall m??te man die Bezierkurve zuerst in Geradenst?cke wandeln und diese dann verschieben. In C w?rde ich das hinbekommen. Eben, das ist das Problem... Dat janze is nich in C programmiert... Oder in irgendeiner anderen Sprache, die mathematische Funktionen beherrscht... Letzteres ist das grundlegende Problem... Man muesste das ganze entweder voelllig neu programmieren in einer Sprache, die die 4 Grundrechenarten beherrscht und paar trigonometrische Funktionen warren auch von Vorteil.. ;-) Oder einen geometrischen Zwischenprozessor dazwischen schalten, wie ich gestern meinte... Dann koennte man Linienstuecke parallel verschieben und die neuen Knoten aus den Kreuzungspunkten der verschobenen Stuecke berechnen. Ist aber auch nur suboptimal, weil viel Rechnerei, Datenmengenvermehrung und evtl. nicht ueberzeugendes Ergebnis, denn bei den Linienabrundungen an den Knoten wrden die Abrundungsradien nicht passen, was spaetestens auffaellt, wenn es ein sehr spizer Knick ist, und bei den Bezier-Kurven wird's knifflig... Das beste wird sein, wir ueberreden die SVG-Macher zu einem neuen Feature ;-) Allerdings: wenn man langfristig das Problem parallel verlaufender Linien loesen moechte, die vernuenftig parallel gezeichnet werden sollen (also der Fall, wo Radwege getrennt gemappt wurden) statt Teilueberlapungen ode Riesenluecken, je nach Zoomfaktor und gemappter Distanz, kommen wir um eine geometrische Vorprozessierung nicht drumrum... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
On Sat, Jan 24, 2009 at 09:17:49AM +0100, BroadwayLamb wrote: Subject: [Talk-de] Hausnummern ...und noch ein Mecker ;) Da ich mich grade ein wenig in die Erfassung von Hausnummern verbissen habe, irritiert mich mal wieder die Darstellung derselben. Mancherorts sieht man vor lauter Hausnummerklecksen nichts anderes mehr (Altstadt MG z.B. - sorry, hab grad keinen Link). War da nicht mal eine Änderung geplant? Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. Die erfahrung zeig so ein bischen das das was nicht gerendert wird auch nicht erfasst wird. D.h. das Hausnummern gerendert werden ist schon wichtig und ich finde osmarender ist schon okay - Mapnik ist die schoene aufgeraeumte Karte fuer Schwiegermutter und Osmarender die wir malen alles fuer die mapper karte ... Und wenn es da mal ein wenig voller wird in den innenstaedten ist das doch okay. Ich finde die neue errungenschafte die Hausnummern die sich den node mit amenitys teilen, rechts neben das eigentliche amenity symbol zu rendern doof. Damit kommt es oft dazu das mitten auf der Straße Hausnummern stehen: http://www.informationfreeway.org/?lat=51.77559071199572lon=8.316189079860315zoom=17layers=BF000F Das Cafe Zur Linde und die Turmschänke haben jeweils eine Hausnummer nur wird die nach rechts verschoben und direkt auf der Straße gerendert. Vorher sind die Hausnummern hinter den Amenity symbolen verschwunden was vollkommen okay war. Hausnummern waeren aber ein super kandidat fuer einen extra layer/overlay der nur auf bedarf angezeigt wird. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Martin Simon grenzde...@gmail.com wrote: construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zur?ckgebaut trifft die Sache einfach besser. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Ich finde das jetzige System mindestens genauso logisch: highway=footway Fuzsgaenger highway=cycleway Cyclisten highway=track Traktoren highway=residential Residierende unterwegs highway=primary Primaten? ;-) highway=construction Konstruktionsmaschinen am Werkeln kighway=planned Verkehrsplaner laufen ueber die Wiese highway=disused Disteln als user... ;-) Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Nun ja... Jede einfache Anwendung muesste sich erstmal durch eine Ist nicht ...-Orgie durchwurschteln... Garry sagt ja was von Garmin-Karten. Dazu fand ich mkgmap im Netz, vermutlich nimmt er das? Dessen styles sind bisher sehr einfach strukturiert: highway=cycleway [0x16 resolution 23] und so weiter... Wollte man da construction=yes, planned=yes, disused=yes, abandoned=yes, ... alles so verarbeiten, dass normale Garmin-Karten-Anwender (auszer Garry mit seinen Spezialwuenschen, die meiner Vermutung nach kontraer dazu sind) dort wirklich nur nutzbare Straszen sehen und keine Hirngespinste, die bisher nur in Planerkoepfen rumspuken, muesste man in jeder Zeile einen Wust von construction = ~|no ... dazwischen setzen, wenn das ueberhaupt so geht, keine Ahnung... Auch im Osmarender ware eine ganze Kaskade von rule-else regeln neotig, die die ganzen highway-Regeln unuebersichtlich macht, waehrend jetzt normal/construction/... voneinander getrennt sind. Ganz chaotisch wuerde es, wenn man beides parallel supporten wollte, was mind. fuer eine Uebergangszeit noetig waere... Die Zahl der Werte bleibt dagegen bei beiden Modellen gleich highway=art status=yes und highway=status status=art sind jeweils immer 2 MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
Heiko Jacobs schrieb: BroadwayLamb broadwayl...@gmx.net wrote: Man muss ja nicht alles von Mapnik kopieren, aber da ist es perfekt gel?st Ohja, da sieht man sie noch besser, weil noch dunkler, soll ich? ;-) und nicht strichliert, also eigentlich noch prominenter... Ja gerne, aber nicht nur dunkler, sondern vor allem viel dünner und als durchgehenden Strich - wie solche Kabel halt aussehen. Im jetzigen Zustand wundere ich mich immer über den vermeintlichen (gestrichelten) Trampelpfad mitten durch die Pampa, der sich bei näherem Hinsehen dann als power line herausstellt. ;) Danke übrigens für die Pipelines. Wenn die jetzt tatsächlich gerendert werden, dann fallen mir spontan einige Stellen ein, bei denen ich dann doch etwas Mapping-Energie investieren könnte. Ja, ja ich weiß - wir mappen nicht für den. Gruß Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
On Sat, Jan 24, 2009 at 11:44:47AM +, Heiko Jacobs wrote: Markus liste12a4...@gmx.de wrote: Was geschieht eigentlich mit solchen und ?hnlichen *W?nschen an die Renderer*? Wer ist das eigentlich: die Renderer? Theoretisch jeder mit svn-account, zumind. bei Osmarender Wie es bei Mapnik laeuft, weisz ich noch nicht... Kann man da auch einfach im style rumpfuschen ;-) und hochladen??? Steve Chilton s.l.chil...@mdx.ac.uk kümmert sich hauptsächlich um die Mapnik Styles. 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] riverbank und wildbach
Hallo, Markus schrieb: _Küstenlinie_ Vergleichbares gibt es auch in Küstengewässern mit starker Tide, oder in flachen Küstengewässern: bei Flut sind sie unter Wasser, bei Ebbe fallen sie trocken. Dort werden (oder sollte) *zwei Küstenlinien* eingetragen: Küstenlinie LAT (bei niedrigst möglichem Wasserstand) http://wiki.openstreetmap.org/wiki/de:Lowest_Astronomical_Tide Küstenlinie NHN (Normalhöhennull) http://de.wikipedia.org/wiki/Normalhöhennull Das Gebiet dazwischen nennt man trockenfallend. Es sollte als blassgrüne Fläche gerendert werden. http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline sagt: A way drawn along the coastline; this should ideally be positioned at the average high tide line. Solange das mittlere Hochwasser der Standard ist, sind LAT und NHN irrelevant für die Bestimmung der Küstenlinie. Übrigens sind geodätische Bezugsflächen generell unbrauchbar für die realitätsnahe Abgrenzung von Land und Wasser. Die Regeln für die zweite Künstenlinie sollte besser ausgearbeitet und dann international diskutiert sowie dokumentiert werden, bevor hier so getan wird, als sei das der Standard. @Markus: Lass uns erst mal die eine Küstenlinie an das mittlere Hochwasser (und zwar das örtliche!) anpassen, bevor wir es komplexer machen - es sei denn, du möchtest vor Ort die Arbeit tun. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
BroadwayLamb schrieb: Danke übrigens für die Pipelines. Dito! Ich freue mich jedesmal, wenn ich mal wieder auf der Karte ein neues Feature finde. Wenn die jetzt tatsächlich gerendert werden, dann fallen mir spontan einige Stellen ein, bei denen ich dann doch etwas Mapping-Energie investieren könnte. Ja, ja ich weiß - wir mappen nicht für den. Bitte den häufig geäußerten Spruch: wir mappen nicht für den Renderer nicht falsch verstehen :-) In erster Linie bedeutet das, wir mappen Dinge nicht anders als sie in der Realität sind, nur damit diese irgendwie auf der Karte erscheinen. Wenn du jetzt anfängst, die Pipelines in deiner Gegend als Stromleitungen einzutragen weil nur diese auch auf der Karte auftauchen ist das von den Daten her ja schlicht falsch - und das ist sehr schlecht. Es ist aus meiner Sicht aber völlig klar, daß Dinge die auf der Karte zu sehen sind allgemein viel eher gemappt werden als Dinge die nur so in der Datenbank stehen. Das ist auch genau der Grund, warum ich beim JOSM versuche möglichst viele der Features darzustellen. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Hallo, Dat janze is nich in C programmiert... hab ich mir gedacht, worin ist es denn programiert? Oder in irgendeiner anderen Sprache, die mathematische Funktionen beherrscht... Wie es gibt sprachen die nicht rechnen können? Da ich nicht weiß wie es läuft spekulier ich mal schnell über ein paar Möglichkeiten und Du sagst was realistisch wäre: -alles neu: funktioniert ist aufwändig -wenn die Software ein anderes Programm aufrufen kann könnte man ein externes Programm schreiben das in irgendeiner Form eine Kurve erhält und den Abstand und daraus eine neue Kurve erzeugt -Man schreibt ein neues Programm, welches das SVG der bestehenden Software weiterverarbeitet. Das ist natürlich Pflickschusterei, wäre aber eine schnelle Möglichkeit, und die Routinen zur Verschiebung könnten ja später in einer vernünftigen Software eingebaut werden. Je nachdem was man der Software beibringen kann könnte sie entweder ein Zusatztag einfügen oder es könnten Eigenschaften wie Farbe, gestrichelt,... mißbraucht werden Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG ???
Hallo, Es gibt keine vernuenftige vollstaendig SVG implementation unter Linux. Nach allem was ich in den letzten Tagen gesehen habe würde es mich wundern wenn es nicht recht einfach wäre einen SVG nach PS Konverter zu schreiben, also gibt es da bestimmt schon was. Und das PS dann ansehen sollte unter Linux kein Problem sein. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo Frederik, danke für Deine wertvollen und detaillierten Vorschläge zur Qualitätssicherung! Ich denke, das sind zukunftsträchtige Ideen, die sich möglicherweise schon in den nächsten OSMXapi-Versionen wiederfinden könnten. - Aktuell besteht ja noch keine Notwendigkeit, denn entsprechend sicherheitsbedürftige Daten liegen noch nicht grossflächig vor (aber das kann sich bei der schnellen Entwicklung von OSM ja bald ändern). _sicherheitsrelevante Objekte_ Mein Wunsch ist es, für sicherheitsrelevante Objekte, beispielsweise ein Leuchtturm für die Schifffahrt, verlässliche Daten zu haben. Meine Idee war, dies über eine besonders sorgfältige - *Qualitätsprüfung bei der Dateneingabe*, und über eine - *red-only*-Funktion der geprüften Daten bei der Datenausgabe zu erreichen. Änderungen an den Daten würden dann genauso wie bei der Dateneingabe die Qualitätsprüfung durchlaufen. Damit wäre gewährleistet, dass Anwendungsprogramme bei sicherheitsrelevanten Objekten nur qualitätsgeprüfte Daten erhalten. Nach aussen würde sich nichts ändern: Der Benutzer sieht im Editor die vorhandenen Daten, ändert sie oder fügt neue hinzu, diese werden geprüft und anschliessend neu angezeigt. Grundsätzlich halte ich es für gar nicht wünschenswert, dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit in die Datenbank einbauen. Warum? Ich könnte mir aber gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also bereits am Eingang zu erzeugen. (Im Gegensatz zu Qualität am Ausgang zu überprüfen und Ausschuss ggf. wegzuschmeissen). Checksummen-Algorithmus Das ist ein wertvolles Instrument für die Eingangsprüfung, beispielsweise zum Vergleich mit amtlichen Daten (zur sicheren Prüfung von Abweichungen), oder mit bestehenden Daten (zur Verhinderung von Tippfehlern, versehentliches Verschieben, etc.). Programme, die Daten auslesen, könnten die Checksumme prüfen und wenn sie nicht zu den Koordinaten passt, den Node ignorieren (oder den Benutzer irgendwie warnen). Eine Ausgabeprüfung würde - Daten einzelner Objekte nicht ausliefern (bei Fehlern) - den Download verlangsamen (durch die Prüfung) sich gegen *absichtliche* Datenänderungen schützen, trust-Weg: Man hat eine Liste von Benutzern, denen man vertraut, und bei bestimmten Objekten verlässt man sich ausschliesslich auf diese Leute Das entspricht der von mir vorgeschlagenen sorgfältigen Eingangsprüfung, und deckt möglichst alle Qualitätsforderungen ab, natürlich auch böswillige Datenänderungen. Qualität bedingt definierte Ziele und Parameter. Sie entsteht durch Menschen, die diese verstanden haben und denen man vertraut diese umzusetzten, verfeinert durch ein Vier-Augen-Prinzip. Jede/r kann Änderungen einbringen. Aber vor der Speicherung in die DB wird diese geprüft. Der Nachteil dabei ist, dass die Eingangsprüfung Zeit braucht, eine Änderung in der DB also nicht in Echtzeit erfolgt. Seezeichen-Qualitätskontrollgruppe mit gemeinsamem OSM-Account alle Seezeichen prüfen und mit unserem Accountnamen abstempeln. und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Ja, das wäre eine Alternative zu read-only. Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung stehen (nicht gestempelte können nicht in der gestempelten Vorversion geladen werden). Wir würden zugleich ein Tool a la OSM-Inspector oder OSM Mapper einsetzen, um schnell zu sehen, wenn irgendjemand eines von unseren Objekten ändert, um diese Änderung dann auch prüfen und abstempeln zu können. In der Eingangskontrolle wären solche Instrumente sehr effizient. Krypto-Tokens, basierend auf public key-Kryptographie. Die Anwendung habe ich noch nicht ganz verstanden. Aber ich erinnere mich, dass ECDIS zur Verifizierung ihrer Daten solche Methoden anwendet (aber eher aus ökonomischen Gründen). Die OSMXapi hat übrigens ein interessantes Feature, das in diese Richtung geht (siehe http://wiki.openstreetmap.org/index.php/Osmxapi#RSS_Feed). Hier wird ein bestimmtes Tag ausgewertet, mit dem Benutzer ein Objekt auf ihre Watchlist setzen können, und selbst wenn andere Benutzer dieses Tag entfernen, wird OSMXapi diese Änderung ignorieren. Es gibt also die Möglichkeit, bei völliger Freiheit in der zentralen OSM-Datenbank, trotzdem einen gefilterten Mirror zu betreiben, der Änderungen nur dann übernimmt, wenn sie nach irgendwelchen programmierten Regeln zulässig sind. Das klingt interessant! Und vielleicht sind gefilterter mirror ja dasselbe wie read-only für einen keinen Bereich von sicherheitsrelevanten Daten Gruss, Markus PS: ich verstehe nicht so viel von DB-Design - aber so rein gefühlsmässig erscheint mir eine
Re: [Talk-de] construction
Heiko Jacobs schrieb: Martin Simon grenzde...@gmail.com wrote: construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zur?ckgebaut trifft die Sache einfach besser. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Ich finde das jetzige System mindestens genauso logisch: highway=footway Fuzsgaenger highway=cycleway Cyclisten highway=track Traktoren highway=residential Residierende unterwegs highway=primary Primaten? ;-) highway=construction Konstruktionsmaschinen am Werkeln kighway=planned Verkehrsplaner laufen ueber die Wiese highway=disused Disteln als user... ;-) Es ist schon längst Zeit das hier auferäumt und der highway - Tag für ways nicht als Zustands-Tag missbraucht wird! Die Einführung von highway=construction war(bzw. ist immer noch) eine Notlösung um nicht freigegeben Strassen nicht als fertig zu rendern. Das ist das einzigste Problem an der Geschichte warum es hier diese Unstimmigkeiten gibt und weiter geben wird so lange da so in den Renderern implementiert ist. Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Nun ja... Jede einfache Anwendung muesste sich erstmal durch eine Ist nicht ...-Orgie durchwurschteln... Garry sagt ja was von Garmin-Karten. Dazu fand ich mkgmap im Netz, vermutlich nimmt er das? Ich nehme die Karten von Computerteddy(für Garmin,TTQV), NaviPowm,... und möchte mir nicht einen eigenen Karten-Style basteln sondern eine allgemeine Darstellung verwenden wie sie seit jeher auf Papierkarten üblich ist - notfalls - falls die gestrichelte Darstellung nicht umgesetzt ist - mit einer entpsrechenden Beschriftung über das name-Tag sowie einer kurzen Unterbrechung im Übergang zum bestehenden Strassennetz darauf hinweisen dass diese Strasse nicht freigegeben ist ! Die Zahl der Werte bleibt dagegen bei beiden Modellen gleich highway=art status=yes und highway=status status=art sind jeweils immer 2 Nur dass man im ersten Fall eine saubere Trennung zwischen highway-Typ und Status hat und im zweiten Fall erst prüfen muss ob es ein Status oder eine Strassenkategorie ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vorschläge zur öonvkarte.de
Hallo Melchior. Zuerst einmal herzlichen Dank zu der wirklich sehr gelungenen ÖPNV-Karte! Neben der Möglichkeit die Liniennetze zu sehen ist Dir auch der restliche Style IMHO sehr gut gelungen. Wirk aufgeräumt und sehr stimmig! Ich habe ein paar Kommentare, Vorschläge und Bitten zu der Karte. Ich werd' diese Mail auch als Kopie an die Talk-DE schicken, damit sich andere dazu äußern können. 1. Farbgebung der Linien Momentan finde ich sind die dunklen Tram/UBahn-Linien zu prominent, vor allem gegenüber den kaum sichtbaren hellen Zugstrecken. Zudem sind Ubahn und tram kaum zu unterscheiden, Verkehren aber in einem ähnlichen Kontext. Mein Vorschlag: - light_rail werden blau (wie jetzt tram) mit dünner Linie. - train werden grün (wie jetzt light_rail) mit dicker Linie, evtl etwas dunkler. - bus bekommt eine dünne rote Linie - tram wird orange (etwas dunkler als jetzt train) und bekommt eine dickere Linie als Bus. - subway wird violett (wie jetzt ferry) und eine dünne Linie. - ferry könnte das dunkle blau der jetzigen subway bekommen. Gründe: - Grün und blau sind relativ dominant auf der Übersichtskarte, das entspricht der überregionalen Bedeutung des Zug-Netzes. - Rot und Orange und violett harmonieren gut miteinander (gehören alle zum lokalen Verkehr) sind aber gut voneinander zu unterscheiden (auch für Farbenblinde). - Die dickeren Linienstärken der tram im lokalen, bzw train im überregionalen Bereich heben ihre Bedeutung hervor. - train und light_rail verkehren meist ebenso auf der selben Trasse wie tram und bus im lokalen Kontext. Dies ist ein weiterer grund für die veränderte Linienstärke: Wenn ein Straßenabschnitt etwa sowohl von tram als auch von bus befahren wird, sehen wir eine feine rote Linie mit einem orangenen Rand für die tram. Das eine überdeckt nicht mehr das andere. 2. Farbgebung der Haltestellen == Analog zu obigem Farbschema könnte man auch bei den Haltepunkten verdeutlichen, welche Fahrzeugart wo hält. Nicht in ein Netz eingebundene Halte sind wie jetzt weiß. Stationen wo ein Bus hält bekommen einen relativ kleinen roten Punkt. Solche mit Tram-Halt einen orangenen Kreis außen rum. (subway einen violetten Punkt) Analog mit train und light_rail. Auf diese Weise kann man leicht sehen, welche ÖPNV-Art wo hält. 3. Umgang mit Haltestellen-Relationen = Vielleicht hast Du mitbekommen, das ich vor kurzem einen Vorschlag gemacht habe, wie man Haltestellen als Relation möglichst vollständig abbilden kann. Hintergrund: Momentan gibt es teilweise 4 oder mehr Haltepunkte für eine Station, entsprechend hässlich sieht es auf der Karte aus, wenn der Stationsname 4 mal auftaucht. Teilweise wird aber auch nur ein einziger Node gemappt für manchmal weit auseinanderliegende Haltepunkte. Zusammenfassung meines Vorschlages: Es gibt mindestens einen Halt mit highway=bus_stop, bzw. railway=station/halt. Dieser liegt AUF dem entsprechenden Weg. Dieser Punkt wird entsprechend in die Route-Relationen aufgenommen. Zudem werden die Orte des Haltestellenschildes/Wartehäusschens/Bahnsteigs NEBEN den Fahrweg an ihrer tatsächliche Position markiert und mit highway=platform markiert (inzwischen tendiere ich allerdings immer mehr zu amenity=platform). Dies alles wird in eine Relation type=site;site=stop_area gepackt und mit Namen, Operator etc versehen. Dieses Schema gilt für alle Systeme (bus,tram,train,...). Vorteile (für Karten wie Deine): Auf niedrigen Zoom-Stufen ränderst Du die vielen zusammengehörigen Haltepunkte als eine einzige Entität, etwa im Schwerpunkt der Relationsmitglieder - Nur noch ein Punkt/Name je Station. In höheren Zoomstufen kannst Du an der Stelle jeder einzelnen Plattform entsprechend ein kleines H-Symbol anzeigen, so dass ich als Nutzer einen genaueren Blick auf die Situation vor Ort haben kann. Wenn Du es interessant findest und es nicht unschaffbar ist, wäre es toll, wenn Du Unterstützung für dieses Schema einbauen könntest. Ich würde mich freuen, wenn wir da zusammen etwas hinbekommen würden. Ich helfe auch gerne, muss allerdings dazu sagen, dass ich mit Rendering noch nie etwas gemacht habe. Also, her mit Kommentaren. Am besten über die Liste. Gruß, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Gerrit Lammert schrieb: 1. Farbgebung der Linien [...] - Die dickeren Linienstärken der tram im lokalen, bzw train im überregionalen Bereich heben ihre Bedeutung hervor. Dem möchte ich ganz stark wiedersprechen, denn bei uns in Berlin spielt der Bus eine wesentlich größere Rolle als die Straßenbahn, die außerdem größtenteils nur im Ost-Teil der Stadt vorhanden ist und aufgrund des Verkehrsrisikos nicht grade beliebt ist und daher IMHO an Bedeutung verliert. - train und light_rail verkehren meist ebenso auf der selben Trasse wie tram und bus im lokalen Kontext. Hier in Berlin spielt train (also Regionalbahn) im ÖPNV kaum eine Rolle und wird daher auch auf den meisten Karten dünn dargestellt. Dies ist ein weiterer grund für die veränderte Linienstärke: Wenn ein Straßenabschnitt etwa sowohl von tram als auch von bus befahren wird, sehen wir eine feine rote Linie mit einem orangenen Rand für die tram. Das eine überdeckt nicht mehr das andere. Das ist allerdings wieder sinnvoll, da dort, wo eine Tram fährt si klar das Straßenbild dominiert. 3. Umgang mit Haltestellen-Relationen Ich finde aus auch Sinnvoll der Übersicht halber zusammengehörige Sationen entsprechend zu verarbeiten. Wichtiger fände ich noch die Richtung (forward, backward) einer Haltestelle zu markieren, z.B. mit solch einem Dreieck wie auf den Linien dann in den weißen Punkt rein. Schlussendlich ist die Gewichtung der Transportmittel (dicke/dünne Linie) sehr schwierig, da man die lokalen Umstände berücksichtigen muss, die von Stadt zu Stadt und von Stadt zu Land unterschiedlich sind. Ich finde die Karte so schon sehr gut. Gruß, Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Markus schrieb: Hallo Sebastian, http://wiki.openstreetmap.org/wiki/Proposed_features/More_access_keys_and_values das ist nicht logisch: Entweder es ist nach Benutzern geordnet: highway=path + agricultural=yes + foot=yes Oder es ist in Access als Gruppe zusammengefasst: highway=path + access=agricultural + acess=foot aber bitte nicht beides oder gar durcheinander. Gruss, Markus Also ich versuchs nochmal zu erklären: Die Schlüssel stellen eine Gruppe von Benutzern mit bestimmten Eigenschaften dar. foot=* für alle die zu Fuß gehen, motorcar=* für alle mit Auto, hgv=* für alle mit LKW. Die Werte legen die Art des Verkehrs fest, der für die jeweilige Gruppe stattfinden darf. 'yes' für vollkommen freie Benutzung, 'destination' für Anlieger-Verkehr, 'no' für garkeine Benutzung. motorcar=no, motorcycle=no, agricultural=yes erlaubt also die Benutzergruppe 'agricultural' für jeden Verkehr. Das entspricht (dem Namen und der Benutzung nach) am ehesten dem Zeichen 1024-17 (Kraftfahrzeuge und Züge, die nicht schneller als 25 km/h fahren können oder dürfen frei). Das ist ganz klar eine Gruppe mit einer bestimmten Fahrzeugeigenschaft. Es dürfen also (vermutlich) Traktoren und Mofas von jedem, aber keine Autos vom Bauern durch, auch wenn ihm das Feld neben dem Weg gehört. motorcar=agricultural, motorcycle=agricultural erlaubt für die Benutzergruppen 'motorcar' und 'motorcycle' den Verkehr 'agrictultural'. Das entspricht dem Zeichen 1026-36 (Landwirtschaftlicher Verkehr frei). Hierbei handelt es sich nicht um eine bestimmte Gruppe mit einer Fahrzeugeigenschaft, sondern um eine Art des Verkehrs, die freigegeben wird. Hier darf also der Bauer zu seinem Feld fahren, egal ob mit dem Auto, dem Motorrad oder dem Traktor, während aber andere Motorfahrzeuge nicht mehr durch dürfen. Würde man nur agricultural=yes für beides benutzen, DANN wäre es eigentlich durcheinander und unlogisch, weil es entgegen der bisherigen Aufteilung geht. Dann müsste man auch destination=yes oder private=yes schreiben können. Wem die Unterscheidung egal ist, dem steht es natürlich weiterhin frei zu benutzen was er will.. :) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausbleibende Löschungen im Wiki
Hallo, On Friday 23 January 2009 23:18:42 Frederik Ramm wrote: Gibt es hier 1-2 Leute auf der Liste, die gerne (einer von mehreren) Sysops beim OSM-Wiki sein würden und sich dann u.a. um solche Sachen kümmern? Es gibt derzeit keine Sysops, die deutsch können, und das ist etwas wenig. Grant hat mich gefragt, ob ich 1-2 Leute empfehlen koennte. Ich würde mich nicht unbedingt darum reißen. Ich habe auch so schon eine ganze Menge zu tun, aber wenn sich sonst keiner findet, könnte ich dieses mit erledigen, da ich die recent changes sowieso schon den ganzen Tag beobachte. Gruß Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen Änderungen schützen
Hallo, Markus wrote: Grundsätzlich halte ich es für gar nicht wünschenswert, dass wir in naher Zukunft irgendeine echte Schutz-/Sperrmöglichkeit in die Datenbank einbauen. Warum? Weil dies eine Macht bei jenen konzentrieren wuerde, die entscheiden, was gesperrt wird und was nicht und wer etwas bearbeiten darf. Solche Machtkonzentration fuehrt fast immer zu einem oder mehreren der folgenden negativen Effekte: * einige Leute fuehlen sich besonders wichtig, es bilden sich Machtstrukturen, Entscheidergremien, Abstimmungen, Anfechtungen von Abstimmungen, Rauswuerfe von Gremienmitgliedern, Anfechtugen von Rauswuerfen und all das * einige Leute sind Flaschenhaelse, an denen immer alles haengenbleibt, und wenn sie mal in Urlaub oder im Real Life ueberarbeitet sind, geht nix mehr * es entstehen komplizierte Authentifikations-/Legitimationsverfahren und ein Ruf nach Sicherheit (wenn Du mit Deinem Account ploetzlich spezielle Bearbeitungsrechte hast, wird Dein Account auch ploetzlich besonders schuetzenswert - man darf dann nur noch Authentifizierung ueber HTTPS machen und solche Scherze); all das bindet Zeit und Arbeitskraft Wenn man hingegen am Ausgang kontrolliert, dann kann jeder Empfaenger selbst definieren, welche Art von Qualitaet er will, wem er trauen will und wem nicht und so weiter; an den zentralen Bottlenecks der Datenbank faellt dadurch keine zusaetzliche Last an, es muessen keine Listen privilegierter Benutzer gefuehrt werden, Editoren muessen nicht angepasst werden... Ich könnte mir aber gut vorstellen, dass man Objekte dadurch schützt, dass man beim Auslesen der Daten gewisse automatisierte Prüfungen macht. Im Qualitätsmanagement ist man seit vielen Jahren zur Erkenntnis gelangt, dass es effizienter ist, *Qualität zu generieren*, sie also bereits am Eingang zu erzeugen. (Im Gegensatz zu Qualität am Ausgang zu überprüfen und Ausschuss ggf. wegzuschmeissen). Diese Lektionen lassen sich m.E. auf OSM keinesfalls uebertragen, zumindest nicht pauschal. Bei OSM gibt es keine zentrale, allen gemeinsame Definition von Qualitaet; was der eine wegwirft, ist fuer den andren wertvoll (bsp. ein 1000m daneben liegender Leuchtturm - wenn ich nur analysieren will, wie die Leuchtturmdichte pro Quadratkilometer in verschiedenen Kuestengebieten ist, dann ist mir das wurscht). Das entspricht der von mir vorgeschlagenen sorgfältigen Eingangsprüfung, und deckt möglichst alle Qualitätsforderungen ab, natürlich auch böswillige Datenänderungen. Eine Eingangspruefung wird es auf absehbare Zeit nicht geben. Dazu fehlen sowohl die technischen Mechanismen als auch der Wille. Jede/r kann Änderungen einbringen. Aber vor der Speicherung in die DB wird diese geprüft. Das wuerde eine Warteschlange von noch nicht genehmigten Aenderungen erfordern, zusammen mit einem Interface und einer privilegierten Personengruppe, die diese Aenderungen bestaetigt, samt Regeln, nach denen sich diese privilegierte Personengruppe konstituiert. Sowas sehen wir fruehestens 2011 und auch dann nur gegen meinen Widerstand ;-) Seezeichen-Qualitätskontrollgruppe mit gemeinsamem OSM-Account alle Seezeichen prüfen und mit unserem Accountnamen abstempeln. und wenn jemand genau unsere abgesegnete Seezeichenkarte will, wird er beim Download halt alles rauswerfen, was nicht von unserem Account kommt. Ja, das wäre eine Alternative zu read-only. Allerdings erreicht man damit nicht, dass immer alle Daten zur Verfügung stehen (nicht gestempelte können nicht in der gestempelten Vorversion geladen werden). Sag das nicht, sowas waere recht leicht ueber ein modifiziertes OSMXAPI machbar (es uebernimmt einfach nur gestempelte). In der Eingangskontrolle wären solche Instrumente sehr effizient. Es wird keine Eingangskontrolle geben. Das widerspricht den Grundprinzipien von OSM. - Eine Eingangskontrolle gibt es bei Google Map Maker, soviel ich weiss. Das klingt interessant! Und vielleicht sind gefilterter mirror ja dasselbe wie read-only für einen keinen Bereich von sicherheitsrelevanten Daten In die Richtung koennte es gehen. Der Vorteil ist das basisdemokratische Element - jeder oder jede Gruppe entscheidet selbst, welche Art von Filterung sie wuenscht/wuenschen; sobald jemand sich bevormundet fuehlt, kann er eine eigene, abweichende Filterung vornehmen. Sind hingegen in der zentralen Datenbank nur gefilterte Daten, steht diese Option nicht mehr offen. 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] Tagging von Gebäudebereichen
On Thu, 22 Jan 2009 12:31:39 +0100, Jutta Weisel ju...@weisel.de wrote: In Marburg ist das Uni-Klinikum privatisiert, nimmt man dann amenity=university oder amenity=hospital ? Noch ein Sonderfall: Wie taggt man ein MPI, das auf dem Campus der Uni steht? Hallo, ich würde amenity=university;hospital machen und in Deinem Spezialfall noch ergänzen operator=Rhön-Klinikum AG. Was das MPI angeht, habe ich ein proposal amenity=research_institution eingereicht (http://wiki.openstreetmap.org/wiki/Proposed_features/research_institution). Wurde aber zurückgewiesen, weil es im eigentlichen Sinne wohl keine Annehmlichkeit ist (was ich auch bei anderen für etwas fraglich halte). Kann ich auch nachvollziehen. Im Moment tendiere ich zu research_institution=yes. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Marc Schütz schue...@gmx.net writes: Ich finde, im jetzigen Zustand der Unordnung Rückwärtskompatibilität einzuführen äußerst kontraproduktiv. Ich sehe das anders. Viele städte in D sind straßenmäßig fertig und in vielen regionen sind auch schon alle hauptverbindungen drin. Da sollte man sich bemühen, nicht noch mehr chaos anzurichten. Wem das mit highway=construction gar nicht zusagt, möge wenigstens highway=road verwenden. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Heiko Jacobs schrieb: SVG kann das offenbar nicht loesen... Gibt es andere Moeglichkeiten, parallel verschobene Linien zu erzeugen irgendwo im Prozess zwischen OSM-Daten auslesen und SVG erzeugen in Osmarender (und Mapnik irgendwann auch)? Vielleicht ein geometrischer Vorprozessor zwischen API und Renderern? SVG an sich hat kein Pfad-Attribut für Offsets, das ist richtig. Allerdings wäre es kein allzu großer Aufwand eine entsprechende Funktion in den Osmarender zu integrieren, sofern man sich an die ORP Variante hält. In welchem Umfang im Moment noch die ältere XSLT Variante in Betrieb ist kann ich allerdings nicht sagen. Das Mapnik keine Unterstützung dafür hat ist für mich etwas verwunderlich. Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, wobei dies in der Momentan vorliegenden Version auch nur im Rastergrafik-Modus funktioniert. Soweit ich gehört habe soll sich das im nächsten Release auch auf die SVG Ausgabe auswirken. Andererseits ist Cobra im Moment noch nicht so Recht für den produktiven Einsatz zu empfehlen. Frederik Fischer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SVG ???
Mit Firefox 3.1b2 unter Windows wird es ohne Fehlermeldung dargestellt. Jedoch kann ich da ja keine Ansichtseinstellungen vornehmen. Ciao André Am 23. Januar 2009 18:37 schrieb Gary68 g...@gary68.de: Hi, wer Interesse hat, mal bei http://www.gary68.de/osm/hof.svg vorbeisehen. DOWNLOAD!, DANN GRAFIKPROGRAMM BETA! - gruppen sind drin - straßen sollten zumindest teilweise beschriftet sein - wege sind zusammenhängend als polyline drin. aber... - wie kann ich die gruppen (in gimp) ein/ausschalten? - firefox steigt gleich aus wegen textPath element. - meine prgs zeigen die beschriftungen nicht. kann an den renderern liegen. bei tests hats auch nur der adobe svg... gebracht. schade, weil ich das ergebnis nicht sehen und verbessern kann. WIE BEKOMME ICH DAS UNTER LINUX ZU SEHEN? ciao Gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Hi Philipp. Philipp Hannasky wrote: - Die dickeren Linienstärken der tram im lokalen, bzw train im überregionalen Bereich heben ihre Bedeutung hervor. Dem möchte ich ganz stark wiedersprechen, denn bei uns in Berlin spielt der Bus eine wesentlich größere Rolle als die Straßenbahn, die außerdem größtenteils nur im Ost-Teil der Stadt vorhanden ist und aufgrund des Verkehrsrisikos nicht grade beliebt ist und daher IMHO an Bedeutung verliert. Berlin ist ein Sonderfall, weil es diesbezüglich ja eher zwei verschiedene Städte sind. Ich denke global hat eine Straßenbahn-Linie auf gleicher Strecke eher weniger Haltepunkte als eine normale Buslinie (Expressbusse mal außen vor). Aber selbst für Berlin: Damit kein optisches Ungleichgewicht entsteht habe ich extra die Farbgebung so vorgeschlagen wie beschrieben. Die jeweils dickere Linie sollte die jeweils unscheinbarere Farbe bekommen. So denke ich nicht, dass eine etwas dickere Linie in sanftem Orange eine schmale aber kräftige rote Linie dominiert. Als Vergleich der Farben siehe hier: http://www.öpnvkarte.de/?lat=53.86487lon=10.67328zoom=16 Ich finde hier dominiert das Rot (was ich an dieser Stelle unangebracht finde, daher mein Vorschlag). Wenn Du Dir jetzt vorstellst, das das rote etwas schmaler und vielleicht noch etwas kräftiger wäre, sehe ich da kein Problem... Hier in Berlin spielt train (also Regionalbahn) im ÖPNV kaum eine Rolle und wird daher auch auf den meisten Karten dünn dargestellt. Also wir taggen ja nicht für den Renderer, aber noch weniger taggen wir für Berlin. :) Im übrigen ist nach Kartenlegende light_rail der Regionalzug und train der Schnellzug. Letzterer ist aber in Berlin anscheinend noch nicht gemappt. Light_rail scheint auch insgesamt eher für S-Bahn verwendet zu werden, während REs bereits als train gelten. Aber darum was wie benannt wird, geht es hier ja nicht... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Hallo, Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, Cobra hab ich ja noch nie gehört, und die deutsche Wikipedia weis dazu auch nur, daß es eine Programiersprache ist. Ging es nicht noch exotischer? Aber egal, was meinst Du mit Offset? Eine einfache Translation reicht ja nicht. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Garry wrote: Ach ja - bei den von mir erfassten Daten verhindere ich die Router-Fehlfunktion zuverlässig in dem ich die in Bau/Plannung befindliche Strassen nicht an öffentliche Strassennetz anschliesse (kleine Unterbrechungen der Ways) - leider wird das von einigen übereifrigen Taggern immer wieder repariert so dass es dann zu dem Router-Problem kommen kann. Lass die Straszen doch verbunden und setzt einfach ein access=no. Grusz Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
@Gerrit: Hast du dich da schon mal mit den international an diesem Thema interessierten OSMlern in der Traffic/Transit-Liste kurzgeschlossen? Ich meine es gibt da ja inzwischen Bestrebungen zu international stimmigen Symbolen und Kartendarstellungen. Vielleicht könnte das also gleich richtig umgesetzt werden. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
wie waers denn mit folgendem schema (aehnlich dem, was schon vor ein paar monaten diskutiert wurde): access:gruppe[optionale einschraenkungen] = art des verkehrs beispiele: das klassische weisse schild mit rotem rand (zeichen 250): access:vehicle = no zeichen 250 mit zusatzschild anlieger frei: access:vehicle = destination zeichen 250 mit zusatzschild fahrraeder frei: access:vehicle = no access:bicycle = yes zeichen 251: access:motorcar = no zeichen 260 mit zusatzzeichen 22-6 h: access:motorcar[2200-0600h] = no access:motocycle[2200-0600h] = no zeichen 262 mit 5,5t drauf und zusatzschild lieferverkehr frei: access:vehicle[5.5t] = delivery analog fuer andere kombinationen... meinungen? 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] Osmarender - cycleway-Darstellung
Dimitri Junker schrieb: Hallo, Wie schon erwähnt wurde, ist Cobra in der Lage mit Offsets umzugehen, Cobra hab ich ja noch nie gehört, und die deutsche Wikipedia weis dazu auch nur, daß es eine Programiersprache ist. Ging es nicht noch exotischer? Aber egal, was meinst Du mit Offset? Eine einfache Translation reicht ja nicht. Dimitri http://wiki.openstreetmap.org/index.php/Cobra Dieses Cobra meinte ich. Mit Offset meine ich eine Projektion des Pfades um einen bestimmten Betrag nach rechts oder links. Eine einfache Translation würde ja, wie von dir erwähnt, nicht ausreichen. ( http://osm.studio-24.net/images/cobra/path_offset.png ) ( http://osm.studio-24.net/images/cobra/dev08091603.jpg ) Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Guenther Meyer schrieb: wie waers denn mit folgendem schema (aehnlich dem, was schon vor ein paar monaten diskutiert wurde): access:gruppe[optionale einschraenkungen] = art des verkehrs beispiele: das klassische weisse schild mit rotem rand (zeichen 250): access:vehicle = no [...] analog fuer andere kombinationen... meinungen? jo :), hab ich auch im talk auf der wiki seite geschrieben. Ich halte es für sinnvoll bei neuen tags ein namespace mit einzuführen, hier halt access:. Das die alten access tags auch in diesem Schema besser aufgehoben wären steht dabei außer frage. Man wüsste halt bei access:hazmat=* gleich worum es ungefähr geht im gegensatz zu nur hazmat=*. Grüße, Fabian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tagging Schema mit Namespace was: Re: construction
Hallo, wäre nicht auch bei der highway=construction vs. construction=yes Problematik eine Lösung ein namespace tagging einzuführen. Man hätte dann: construction:highway=primary anstatt highway=construction und construction=primary bzw. highway=primary und construction=yes Vorteile: - Wenn man eine Karte nur mit im Bau befindlichen Objekten haben will, oder diese eben gar nicht haben will, sucht man nach dem construction: namspace und filtert über diesen. Vorgehen, wie bei construction=yes. - Ein Renderer muss nicht bei jedem highway etc. eine Abfrage starten ob ein construction=yes vorliegt um diesen zu Rendern, selbst wenn es keinen hat. Nur eine Abfrage des Renderers wie bei highway=construction (nicht 2 Abfragen wie bei highway=primary und construction=yes) - Nur ein Tag nötig - In dem einen Tag wird alles deutlich. Nachteil: Den einzigen den ich sehe, es wird bisher nicht unterstützt :) Das Problem sollte aber denke ich lösbar sein (ersetzung der Regeln von highway=construction mit construction:highway=*) Einfach mal drüber nachdenken, evtl. ist es ja ein hilfreicher Lösungsansatz. Ich empfinde es momentan als ziemlich praktisch und logisch, aber vielleicht übersehe ich auch gerade Nachteile. Grüße, Fabian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Hi Claudius. Claudius Henrichs wrote: @Gerrit: Hast du dich da schon mal mit den international an diesem Thema interessierten OSMlern in der Traffic/Transit-Liste kurzgeschlossen? Ich meine es gibt da ja inzwischen Bestrebungen zu international stimmigen Symbolen und Kartendarstellungen. Vielleicht könnte das also gleich richtig umgesetzt werden. Ja, dort schreib ich auch. Aber dort kamen auch nur 1-2 joa, find ich ganz sinnvoll antworten und wenig handfestes. Diese Haltestellengeschichte ist mir schon unangenehm an OSM aufgefallen, seit ich vor 2 zwei Jahren das erste Mal damit zu tun hatte (habe OSM-Daten benutzt um darauf Busrouting zu machen). und seitdem hat sich nicht viel in der Sache getan. Die Relations für die Routen sind ein immenser Fortschritt, aber die Stop-Problematik besteht weiterhin. Inklusive der Uneinigkeit ob Stops neben oder auf dem Weg getaggt werden sollen. Was das angeht hab ich mich selbst immer mal wieder umentschieden, je nachdem aus welchem Gesichtspunkt ich das betrachtet habe. Aus genau diesem Grund hab ich das beschriebene vorgeschlagen, da es sehr viele von den mir mit dem Status Quo begegneten Problemen lösen würde und (das finde ich ganz wichtig) flexibel, eiinfach und erweiterbar ist. Das ich auf den verschiedenen Listen und Threads praktisch keinen Widerspruch gehört habe, freut mich zwar zum einen, aber da sich auf der anderen Seite auch niemand für die häufiger in diesem Zusammenhang angesprochene Frage wie denn nun die Platform zu taggen sei interessiert, gehe ich eher davon aus, dass insgesamt kein großes Interesse an dem Thema ÖPNV besteht oder zumindest an einer Verbesserung des Status Quo. Daher verspreche ich mir von einer Renderunterstützung dieses Schemas auch a) ein größeres Interesse und b) die Chance Fehler oder Schwachstellen leichter zu ermitteln. Das war jetzt vermutlich viel mehr Information als Du haben wolltest, aber ich hab gerade Zeit. :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Hallo, Zitat von silversurfer silversur...@oleco.net: ich würde amenity=university;hospital machen Verstehen das die Renderer? Ein Krankenhaus ist doch so wichtig, dass es schon jetzt richtig angezeigt werden sollte. und in Deinem Spezialfall noch ergänzen operator=Rhön-Klinikum AG. Gute Idee. Was das MPI angeht, habe ich ein proposal amenity=research_institution eingereicht (http://wiki.openstreetmap.org/wiki/Proposed_features/research_institution). Wurde aber zurückgewiesen, weil es im eigentlichen Sinne wohl keine Annehmlichkeit ist (was ich auch bei anderen für etwas fraglich halte). Kann ich auch nachvollziehen. Im Moment tendiere ich zu research_institution=yes. Das beschreibt es sicher gut, ist aber als Tag kaum genutzt, oder? Man könnte hier auch ein operator=Max Planck Gesellschaft dranhängen. - Jutta -- http://www.weisel.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation über Kreisverkehr
Hallo Liste, Wie tagge ich eine Relation über einen Kreisverkehr? 1) Ist der Kreisverkehr komplett ein Teil der Relation? Dann wäre dort ein Bruch der Relation. 2) Nehme ich den Kreisverkehr nicht mit in die Relation auf? Dann wäre dort ein Loch in der Relation. 3) Spalte ich den Kreisverkehr so auf, dass er in die Relation passt, wie man es bei anderen Wegen auch macht? Dann wäre die Relation durchgängig. Schon mal vielen Dank für die Hilfe. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Torsten Leistikow wrote: Andreas Labres schrieb: Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Es gibt ein leisure=sports_centre. Naja... daß ein Areal mit so ein paar Fußballplätzen oder ein Tennisclub ein sports_centre sein könnte, lasse ich mir ja noch einreden, aber ein Gym? Ich hab mittlerweile einen Thread in talk gefunden, dort wurde auch sports_centre erwähnt und wieder verworfen. Dort war der Clue leisure=fitness_center, das macht wohl den meisten Sinn. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Jutta Weisel schrieb: Hallo, Zitat von silversurfer silversur...@oleco.net: ich würde amenity=university;hospital machen Verstehen das die Renderer? Nein. Und wenn ich wetten müßte, wird das auch nicht so schnell passieren. Im JOSM z.B. würde es die Kartendarstellung wohl langsamer machen. Ein Krankenhaus ist doch so wichtig, dass es schon jetzt richtig angezeigt werden sollte. Sehe ich auch so. Die Hauptanwendung ist doch eher das Hospital. Ein Mitarbeiter könnte natürlich auch argumentieren: Das ist hier eine Universität, die Patienten behandeln wir nur nebenbei ;-) Was das MPI angeht, habe ich ein proposal amenity=research_institution eingereicht (http://wiki.openstreetmap.org/wiki/Proposed_features/research_institution). Wurde aber zurückgewiesen, weil es im eigentlichen Sinne wohl keine Annehmlichkeit ist (was ich auch bei anderen für etwas fraglich halte). Kann ich auch nachvollziehen. Im Moment tendiere ich zu research_institution=yes. Das beschreibt es sicher gut, ist aber als Tag kaum genutzt, oder? Bislang genau drei mal. Daneben gibt es dann noch: institute research research_centre ... und vielleicht noch andere. Trag es halt erstmal so ein wie du meinst, wenn sich da eine erkennbare Häufung gebildet hat kann man immer noch aufräumen. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Kann man die Nummern nicht einfach wie bei Google anzeigen? Müssen wir es unbedingt ANDERS machen? Ich finde, dass einfach die Zahl ausreicht, evtl. nicht schwarz sondern grau. Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Jutta Weisel schrieb: Ich habe gesehen, Deine Gebäude sind mit amnity=university und building=yes getaggt. So habe ich es auch gemacht, sehe aber in den Mapnik-Rules, dass die Polygon-Rules zu building=yes die zu anmity=university überschreiben. Frage: sind die Rules falsch oder die Tag-Kombination? Falsch ist so ein hartes Wort ;-) Die Angewohnheit überall ein building=yes dranzumachen ist ja im Gros der Mapperschaft noch recht neu (wie Gebäude überhaupt als Flächen einzuzeichnen), daher sind die Renderer da auch noch nicht sooo fortschrittlich. Das building=yes macht aus meiner Sicht aber durchaus Sinn. Beim Josm greift die Regel für building=yes nur mit niedriger Priorität, ein amenity=university greift eher und wird entsprechend dargestellt. Die anderen Renderer sollten dementsprechend angepaßt werden. Bitte nimm dir die Zeit und trag solche Sachen doch als Bug ein - sonst wird es ja nie besser ;-) Gleiches gilt übrigens auch für amenity=hospital und buildung=yes. Damit kommt auch der Osmarender nich zurande, er bringt den Namen ein zweites Mal über dem roten Kreuz. Auch da ist halt noch Optimierungspotential. Gruß, ULFL P.S.: Bitte lass doch etwas mehr Sorgfalt bei der key/value Schreibweise walten! In deiner Mail waren mehrere Tippfehler drin, z.B. buildung=yes - damit lernen Neulinge die Sachen doch nie richtig zu schreiben ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - Voting - More access keys and values
Am Samstag 24 Januar 2009 schrieb Sebastian Hohmann: Fabian -Patzi- Patzke schrieb: Guenther Meyer schrieb: wie waers denn mit folgendem schema (aehnlich dem, was schon vor ein paar monaten diskutiert wurde): access:gruppe[optionale einschraenkungen] = art des verkehrs beispiele: das klassische weisse schild mit rotem rand (zeichen 250): access:vehicle = no [...] analog fuer andere kombinationen... meinungen? jo :), hab ich auch im talk auf der wiki seite geschrieben. Ich halte es für sinnvoll bei neuen tags ein namespace mit einzuführen, hier halt access:. Das die alten access tags auch in diesem Schema besser aufgehoben wären steht dabei außer frage. Man wüsste halt bei access:hazmat=* gleich worum es ungefähr geht im gegensatz zu nur hazmat=*. Grüße, Fabian Da hab ich auch nichts dagegen, nur geht es bei dem Proposal lediglich um neue Schlüssel und Werte. Ich finde es nicht sinnvoll eine neues Schema nur für einige Tags einzuführen, das würde nur Verwirrung stiften. Schließlich gliedern die sich alle in die access-Gruppen ein und sollten auch einheitlich behandelt werden. mein weg geht in die richtung, die gesamte access-gruppe zu vereinheitlichen. alles andere ist nur rumgebastel, finde ich... Meiner Meinung nach wäre es besser ein extra Proposal dafür zu erstellen (oder gibt es das schon?), wo man die Möglichkeit hat das neue Schema zu disktutieren. es gab vor einiger zeit eine diskussion dazu auf der liste, aber soweit ich weiss, hat niemand daraus ein proposal gemacht. Wer es will kann es ja sowieso schon einsetzen, es gibt schließlich keine Beschränkungen was die Tags angeht. Wenn genug Leute es für sinnvoll halten, setzt es sich auch durch. Man muss nur darauf hinweisen und das geht am besten über ein Proposal (für das natürlich auch Werbung gemacht wird). richtig. 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
[Talk-de] Karten in JOSM einblenden
Hallo, kann ich eigenes Bildmaterial in JOSM einblenden lassen? Ich bin Orts-Chronist in meinen Dorf und wir haben vor einigen Jahren selbst eine Karte für eine Publikation erstellt, eigene Rechte liegen also vor. Nun würde ich ja gerne das selbst nutzen. Außerdem habe ich einiges Material älter als 70 Jahre, also frei von Urheberrechten. Grüße, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation über Kreisverkehr
Fabian -Patzi- Patzke schrieb: Ich habe, wenn es bei mir vorkam, immer den ganzen Kreisverkehr reingemacht, schadet finde ich nicht. Das denke ich auch. Ich finde, dass eine Relation, z.B. eine Route, auch immer den gesamten Kreisverkehr enthalten sollte. So hab ich es halt gemacht, siehe z.B. http://www.öpnvkarte.de/?lat=51.92595lon=10.43604zoom=17 Da geht die Busroute auch durch den ganzen Kreisel. Die meisten Routen sind ja auch nicht gerichtet. Insofern haette man, je nach Richtung, sowieso einmal die eine und einmal die andere Seite vom Kreisverkehr mit drin. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
On Sat, 24 Jan 2009 16:42:59 +0100, Jutta Weisel ju...@weisel.de wrote: Verstehen das die Renderer? Ein Krankenhaus ist doch so wichtig, dass es schon jetzt richtig angezeigt werden sollte. Jetzt gibt es ja auch ein Proposal für healthcare (http://wiki.openstreetmap.org/wiki/Proposed_features/healthcare). Man darf also gespannt sein. Grischa ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten in JOSM einblenden
Am 24.01.2009 17:56, Arne Bischoff: kann ich eigenes Bildmaterial in JOSM einblenden lassen? Ich bin Orts-Chronist in meinen Dorf und wir haben vor einigen Jahren selbst eine Karte für eine Publikation erstellt, eigene Rechte liegen also vor. Nun würde ich ja gerne das selbst nutzen. Außerdem habe ich einiges Material älter als 70 Jahre, also frei von Urheberrechten. 1.) Mithilfe des Metacarta Mac Rectifiers referenzierst du dein Bildmaterial mit Geokoordinaten: http://labs.metacarta.com/rectifier/ 2.) In JOSM verwendest du dann das Plugin wmsplugin und im dann angezeigten Menü WMS - Berichtiges Bild. Dort gibst du die Nummer deines bei obiger Seite hochgeladenen Bildes an. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öonvkarte.de
Hallo Gerrit, 1. Farbgebung der Linien Momentan finde ich sind die dunklen Tram/UBahn-Linien zu prominent, vor allem gegenüber den kaum sichtbaren hellen Zugstrecken. Zudem sind Ubahn und tram kaum zu unterscheiden, Verkehren aber in einem ähnlichen Kontext. Mein Vorschlag: - light_rail werden blau (wie jetzt tram) mit dünner Linie. - train werden grün (wie jetzt light_rail) mit dicker Linie, evtl etwas dunkler. - bus bekommt eine dünne rote Linie - tram wird orange (etwas dunkler als jetzt train) und bekommt eine dickere Linie als Bus. - subway wird violett (wie jetzt ferry) und eine dünne Linie. - ferry könnte das dunkle blau der jetzigen subway bekommen. Mit meinem Farbschema bin ich momentan auch nicht ganz zufrieden, allerdings hadere ich auch damit alles komplett über den Haufen zu werfen. Dein Schema überzeugt mich ehrlich gesagt auch nicht vollständig. 1. weil das Grün der Züge in der Übersicht in den Grünflächen verschwindet. 2. weil Blau für Fähren auf dem Wasser auch nicht ideal ist. Mein Ziel wäre mittelfristig auch die Farben nicht von den Tags abhängig zu machen, da die fast nach belieben verwendet werden, sondern von den Haltestellenabständen. 2. Farbgebung der Haltestellen == Analog zu obigem Farbschema könnte man auch bei den Haltepunkten verdeutlichen, welche Fahrzeugart wo hält. Nicht in ein Netz eingebundene Halte sind wie jetzt weiß. Stationen wo ein Bus hält bekommen einen relativ kleinen roten Punkt. Solche mit Tram-Halt einen orangenen Kreis außen rum. (subway einen violetten Punkt) Analog mit train und light_rail. Auf diese Weise kann man leicht sehen, welche ÖPNV-Art wo hält. Das wäre natürlich sehr gut, ich habe momentan nur leider nicht die Haltestellen der Relationen in der Datenbank 3. Umgang mit Haltestellen-Relationen = Vielleicht hast Du mitbekommen, das ich vor kurzem einen Vorschlag gemacht habe, wie man Haltestellen als Relation möglichst vollständig abbilden kann. Hintergrund: Momentan gibt es teilweise 4 oder mehr Haltepunkte für eine Station, entsprechend hässlich sieht es auf der Karte aus, wenn der Stationsname 4 mal auftaucht. Teilweise wird aber auch nur ein einziger Node gemappt für manchmal weit auseinanderliegende Haltepunkte. Zusammenfassung meines Vorschlages: Es gibt mindestens einen Halt mit highway=bus_stop, bzw. railway=station/halt. Dieser liegt AUF dem entsprechenden Weg. Dieser Punkt wird entsprechend in die Route-Relationen aufgenommen. Zudem werden die Orte des Haltestellenschildes/Wartehäusschens/Bahnsteigs NEBEN den Fahrweg an ihrer tatsächliche Position markiert und mit highway=platform markiert (inzwischen tendiere ich allerdings immer mehr zu amenity=platform). Dies alles wird in eine Relation type=site;site=stop_area gepackt und mit Namen, Operator etc versehen. Dieses Schema gilt für alle Systeme (bus,tram,train,...). Wenn das so durchgehend umgesetzt würde wäre das für die Karte natürlich schön. Meine Idee wäre einfach die Haltestellen in einem gewissen Umkreis mit ähnlichem Namen in der Übersicht zusammenzufassen, das würde eine Menge Mapping Arbeit sparen. Auch wenn ich so auf die schnelle nichts umsetzen kann, danke für die Anregungen. Gruß, Melchior ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation über Kreisverkehr
Torsten Leistikow schrieb: Fabian -Patzi- Patzke schrieb: Ich habe, wenn es bei mir vorkam, immer den ganzen Kreisverkehr reingemacht, schadet finde ich nicht. Das denke ich auch. Ich finde, dass eine Relation, z.B. eine Route, auch immer den gesamten Kreisverkehr enthalten sollte. So hab ich es halt gemacht, siehe z.B. http://www.öpnvkarte.de/?lat=51.92595lon=10.43604zoom=17 Da geht die Busroute auch durch den ganzen Kreisel. Die meisten Routen sind ja auch nicht gerichtet. Insofern haette man, je nach Richtung, sowieso einmal die eine und einmal die andere Seite vom Kreisverkehr mit drin. Gruss Torsten Nur zeigt dann der Relation-Check unter betaplace.emaitie.de Brüche in der Relation. Deshalb war ich mir nicht mehr ganz sicher, Gruß, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
Florian Lohoff schrieb: Vorher sind die Hausnummern hinter den Amenity symbolen verschwunden was vollkommen okay war. nein... das fand ich überhaupt nicht ok. ich hab mir so viel mühe gegeben mit den Hausnummern, da möchte ich doch nicht, dass jede 2. von einem symbol überdeckt wird. Hausnummern waeren aber ein super kandidat fuer einen extra layer/overlay der nur auf bedarf angezeigt wird. das wäre die beste Lösung. dann muss man dieses Overlay aber auch entdecken und anschalten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
On Sat, 24 Jan 2009 19:11:38 +0100, Jutta Weisel ju...@weisel.de wrote: Ich habe mir gerade überlegt, dass das vielleicht doch Sinn macht, nämlich wenn man den Campus mit amenity=university oder hospital taggt und die Gebäude auf dem Campus zusätzlich mit building=yes. Das wird zumindest auch in Berlin mit HU, TU und FU so gemacht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation über Kreisverkehr
Peter Vitt pe...@dotnetphen.com writes: 3) Spalte ich den Kreisverkehr so auf, dass er in die Relation passt, wie man es bei anderen Wegen auch macht? Dann wäre die Relation durchgängig. Ja, aufsplitten. Und den kreisverkehr selbst auch wieder in eine relation packen. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Am 24. Januar 2009 17:12 schrieb Andreas Labres l...@lab.at: Torsten Leistikow wrote: Andreas Labres schrieb: Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Es gibt ein leisure=sports_centre. Naja... daß ein Areal mit so ein paar Fußballplätzen oder ein Tennisclub ein sports_centre sein könnte, lasse ich mir ja noch einreden, aber ein Gym? Ich hab mittlerweile einen Thread in talk gefunden, dort wurde auch sports_centre erwähnt und wieder verworfen. Dort war der Clue leisure=fitness_center, das macht wohl den meisten Sinn. Servus, Andreas aber lieber schön britisch fitness_centre Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Gebäudebereichen
Jutta Weisel schrieb: Ich habe mir gerade überlegt, dass das vielleicht doch Sinn macht, nämlich wenn man den Campus mit amenity=university oder hospital taggt und die Gebäude auf dem Campus zusätzlich mit building=yes. Das passt allerdings nicht zu den JOSM-Vorlagen, da wird amenity=university unter Gebäude angeboten. Die JOSM Presets sind ja auch eher für die einfachen Fälle gedacht ;-) Übrigens: Wenn die einzelnen (größeren) Häuser Namen oder Nummern haben (was ja meist der Fall ist), die auch ruhig eintragen. Mapnik zeigt das dann ab Z16 recht schön an: http://openstreetmap.org/?lat=49.41848lon=11.11841zoom=16layers=B000FTF Wenn ich da irgendwo hinwill, ist das ja durchaus informativ wohin ich eigentlich genau muß ;-) Bitte nimm dir die Zeit und trag solche Sachen doch als Bug ein - sonst wird es ja nie besser ;-) Wie geht das? Oder meinst Du http://wiki.openstreetmap.org/wiki/OpenStreetBugs? Nein, ich meine die jeweiligen Bugtracker (für Slippy Map, Mapnik, JOSM, ...), die du unter: http://wiki.openstreetmap.org/wiki/Develop in der Spalte Bugs findest. P.S.: Bitte lass doch etwas mehr Sorgfalt bei der key/value Schreibweise walten! In deiner Mail waren mehrere Tippfehler drin, z.B. buildung=yes - damit lernen Neulinge die Sachen doch nie richtig zu schreiben ;-) Da hast Du recht, ich gelobe Besserung! Sehr schön! Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Martin Simon grenzde...@gmail.com [Sat, Jan 24, 2009 at 11:02:34AM CET]: [...] construction=yes oder besser life_cycle=wunschtraum/im bau/brachliegend/zurückgebaut trifft die Sache einfach besser. Nicht zu vergessen den Zustand in musealen Zustand versetzt. So etwas vermisse ich schmerzlich. Eine Trasse im Bau ist eine Trasse. ein - Moment ;) - Atomkraftwerk ebenfalls. Ein Atomkraftwerk in Bau ist eine Trasse? Zudem braucht es bei construction= oder life_cycle= nur einen key und 1-~5 values, die ein renderer, router oder mkgmap brauchen, um alle diese von normalen Menschen noch nicht oder nicht mehr nutzbaren Objekte mit einem Rutsch zu entsorgen. Es gab bei den jüngeren Ansätzen für ein solches Modell zweifache Opposition. Die einen hassten den Ausdruck life_cycle so sehr, dass sie allein aufgrund dieses Wortes entschlossen waren, das Konzept abzulehnen. Die anderen folgten einer ähnlichen Argumentation wie Heiko. Wenn man bei jedem Element erst nachschauen muss, ob es noch in Betrieb ist, so wird der Code-Wust größer. Den ersten Einwand kann ich nicht ernstnehmen, würde aber um den Wortlaut nicht streiten wollen. Hauptsache, das Konzept existiert, da kann sich die Gegenseite gerne das Wort aussuchen, von mir aus auch grungelborz. Der zweite Einwand ist ernst zu nehmen. Könnte man den Leuten, die hier Furcht hegen, soweit entgegenkommen, dass man dreimal wöchentlich ein frisches gefiltertes .osm bereitstellt, aus dem alle highways herausgefiltert sind, die grungelborz != active sind? Nur so eine Idee. -- 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] Hausnummern
2009/1/24 Josias speak...@j-po.de Florian Lohoff schrieb: Vorher sind die Hausnummern hinter den Amenity symbolen verschwunden was vollkommen okay war. nein... das fand ich überhaupt nicht ok. ich hab mir so viel mühe gegeben mit den Hausnummern, da möchte ich doch nicht, dass jede 2. von einem symbol überdeckt wird. ich wäre auch eher dafür, die Nr. unten zu rendern, also über der Karte, unter Icons, unter Text. Wenn ein paar auf der allgemeinen gerenderten Karte dann verdeckt werden, ist das doch nicht so tragisch, wichtig ist, dass sie drin sind und gefunden werden. Hausnummern waeren aber ein super kandidat fuer einen extra layer/overlay der nur auf bedarf angezeigt wird. das wäre die beste Lösung. dann muss man dieses Overlay aber auch entdecken und anschalten. ja, in der Karte finde ich sie schon an sich sinnvoll, allerdings (das schreibe ich schon regelmäßig seit es sie gibt) würde es ausreichen, wenn sie als kleine schwarze Zahl ohne Hintergrund oder Umrandung dargestellt würden, da stören sie dann auch die empfindsameren Zeitgenossen nicht mehr. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
BroadwayLamb wrote: ...und noch ein Mecker ;) Da ich mich grade ein wenig in die Erfassung von Hausnummern verbissen habe, irritiert mich mal wieder die Darstellung derselben. Mancherorts sieht man vor lauter Hausnummerklecksen nichts anderes mehr (Altstadt MG z.B. - sorry, hab grad keinen Link). War da nicht mal eine Änderung geplant? Nach meiner bescheidenen Meinung würde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem dünnen Ring außen herum - quasi das Negativ der jetzigen Darstellung. IIRC ist das prominente Rendering eingeführt worden, nachdem das Karlsruhe-Schema entwickelt wurde, um die Fortschritte hier gleich ganz drastisch sichtbar zu machen. Hintergedanke war wohl, wenn das Hausnummern-mappen einmal etabliert ist, die Sichtbarkeit wieder zurückzufahren. Im Mailinglisten-Archiv müsst man das nachlesen können. lg roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] riverbank und wildbach
2009/1/23 Garry garr...@gmx.de Hermann Schwärzler schrieb: soll ich die hochwasser-ufer-linie (also meist den schutzdamm) als riverbank eintragen? oder wie macht ihr das? Riverbank wäre glaube ich ungünstig.. Vor längere Zeit waren hier mal Wadis im Gespräch - vielleicht hilft Dir das Stichwort weiter... Wadi scheint mir recht speziell zu sein (Wikipedia: Wadi= bezeichnet einen zeitweilig austrocknenden Flusslauf in einem Trockentalhttp://de.wikipedia.org/wiki/Trockentalin den Wüstengebieten http://de.wikipedia.org/wiki/W%C3%BCste Nordafrikashttp://de.wikipedia.org/wiki/Nordafrika, Vorderasiens http://de.wikipedia.org/wiki/Vorderasien und teilweise Spaniens http://de.wikipedia.org/wiki/Spanien. Im Südwesten Afrikas werden solche Trockenflüsse Riviere http://de.wikipedia.org/wiki/Rivier genannt, in Australien Creeks http://de.wikipedia.org/wiki/Creek, in Süd- und Teilen Nordamerikas Arroyos und auf Spanisch Barranco. Riverbank ist prinzipiell nicht falsch für die äußere Grenze, weil dort ja das Flussufer ist, auch wenn der Fluss überwiegend nicht bis dort hinkommt, dennoch wird man das Flussbett nicht wie die übrige Umgebung klassifizieren wollen. Wenn man es genau machen will, wird man sich wohl was spezielles Ausdenken müssen (ich würde die äußere Grenze als normal mappen und die innere, wenn der Fluss wenig Wasser hat, als Spezialfall, weil man wohl das gesamte maximal genutzte Areal als Flussbett bezeichnen wird). Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Karte: Main in Frankfurt ausgetro cknet
Hi Markus, Markus Stürmer schrieb: Auf [1] steht: Do not add natural=water to the way since this is intended for areas forming lakes. Aha. Na dann eben nicht. Was ist ein Teich? Oder sonst eine Wasserfläche, die kein See ist? (Altarme z.B. von Flüssen, die sind eigentlich ja keine Flüsse mehr oder?) natural=water tags entfernt. Das die Namen an den Riverbanks auch entfernt wurden hat den Grund, dass somit durch die Linie (waterway=river) und die Fläche Namen gerendert wurden, wobei die der Fläche öfter auch außerhalb des Mains lagen. Ich gehe immer noch von dem Grundsatz aus, dass wir nicht für den Renderer Mappen sondern für die Karte, wenn die Renderer die Namen außerhalb der Karte erzeugen, dann ist nicht die Karteninfornation falsch, sondern der Renderer muß korrigiert werde. Mein Renderer heißt mkgmap und der hat den Namen imemr auf der Fläche gehabt. Die Inseln/Staustufen habe ich in Relationen gepackt, da diese von Mapnik und Osmarender unterstützt werden und normalerweise keine Probleme mehr bereiten (ab und an hat Mapnik noch mit der Richtung der Wege Probleme). Warum Relationen einführen wo es nicht notwendig ist. Ich wundere mich nur, dass Du das geändert hast. Was ist besser an der Relation als an der vorherigen Methode? Wie auf [2] zu entnehmen und auch von Frederik mehrfach auf der Mailingliste und anderweitig angemerkt ist es nicht nötig den inneren Weg einer Multipolygon-Relation mit Tags zu versehen. Daher haben sie meist auch keinen, wenn ich das anfasse. Sollte auf den Inseln etwas anderes sein, als nur kein Wasser, dann kann man Tags vergeben, z.B. natural=scrub ... Von mir aus kann man das für neue Sachen ja verwenden, auf Teufel komm raus alte funktionierende Sachen zu ändern, dafür haben wir eigentlich noch genügend Anderes zu tun, auch in Frankfurt. Von mir aus kann es ja so bleiben, ich werde mich persönlich nicht der Relationitis anschließen, und in der Garminkarte siehts halt im Moment doof aus, da ich Inseln eben nur dann aus dem Wasser heben kann, wenn da Land getaggt ist. (Oder die Insel aus dem Wasser ausgespart ist) -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Am Samstag 24 Januar 2009 14:48:22 schrieb Karl Eichwalder: Marc Schütz schue...@gmx.net writes: Ich finde, im jetzigen Zustand der Unordnung Rückwärtskompatibilität einzuführen äußerst kontraproduktiv. Ich sehe das anders. Viele städte in D sind straßenmäßig fertig und in vielen regionen sind auch schon alle hauptverbindungen drin. Da sollte man sich bemühen, nicht noch mehr chaos anzurichten. Ich habe damit das bereits bestehende Chaos im Tagging gemeint. Es ist ganz gut, in der Anfangsphase freies Tagging zu betreiben, weil sich erst noch herausstellen muss, was man eigentlich alles in die Karte aufnehmen will, und wie man das am besten darstellt. Aber jetzt auf Kompatibilität zu pochen, führt nur dazu, dass die vielen Fehler, die zweifellos gemacht worden sind, für immer festzementiert werden. Man könnte die durch Änderungen am Taggingschema entstehenden Unstimmigkeiten sogar als Ansporn/Druckmittel ansehen, beim nächsten Tag, den man erfindet, lieber vorher nachzudenken, wie man ihn so gestaltet, dass er sich mit zukünftigen Erweiterungen gut verträgt. Irgendwann sollte man dann hergehen und zumindest einen Teilbereich der Tags als festen Standard definieren, natürlich unter Berücksichtigung der _Vorwärts_kompatibilität, alle Benutzer (Mapper und Datenverwerter) eindringlich dazu auffordern sich dranzuhalten, und vielleicht auch per Bot die Daten daran anpassen. Erst dann macht Rückwärtskompatibilität richtig Sinn, weil es vorher ja noch nicht mal einen Standard gibt, zu dem kompatibel sein kann. Grüße, Marc 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] riverbank und wildbach
Martin Koppenhoefer schrieb: Riverbank ist prinzipiell nicht falsch für die äußere Grenze, weil dort ja das Flussufer ist, auch wenn der Fluss überwiegend nicht bis dort hinkommt, dennoch wird man das Flussbett nicht wie die übrige Umgebung klassifizieren wollen. Wenn man es genau machen will, wird man sich wohl was spezielles Ausdenken müssen (ich würde die äußere Grenze als normal mappen und die innere, wenn der Fluss wenig Wasser hat, als Spezialfall, weil man wohl das gesamte maximal genutzte Areal als Flussbett bezeichnen wird). Ich weiss ja nicht wie das vor Ort aussieht, wenn da kein Wasser ist, aber das waere fuer mich das Entscheidende. Beim Wattenmeer habe ich z.B. kein Problem damit, dass man das als Wasserflaeche ansieht, die zeitweise trocken liegt. Wenn es im Ueberschwemmungsbereich aber normalen Pflanzenbewuchs (Gras, Baeume) gibt, dann scheint mir da riverbank nicht angemessen. Nur weil eine Wiese mal ueberschwemmt werden kann, bleibt sie doch eine Wiese und wird nicht pauschal zum Fluass. Da wuerde ich dann eher bei natural=wetland mal gucken, ob man da nicht was passendes finden (oder eventuell hinzufuegen) kann. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osmrender.pl version 2 veröffentlich t
hi, obwohl das programm sicher nie fertig wird (aber es soll sich ja auch jeder anpassen), habe ich mal eine zweite version veröffentlicht. sie erstellt nun auch - SVG dateien - straßennamen siehe beispiel hier: http://www.gary68.de/osm/hof.svg viel spaß damit download von meiner wiki seite http://wiki.openstreetmap.org/wiki/User:Gary68 doku hier http://wiki.openstreetmap.org/wiki/Osmrender.pl http://wiki.openstreetmap.org/wiki/Osmgraph.pm gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Christian Koerner schrieb: Garry wrote: Ach ja - bei den von mir erfassten Daten verhindere ich die Router-Fehlfunktion zuverlässig in dem ich die in Bau/Plannung befindliche Strassen nicht an öffentliche Strassennetz anschliesse (kleine Unterbrechungen der Ways) - leider wird das von einigen übereifrigen Taggern immer wieder repariert so dass es dann zu dem Router-Problem kommen kann. Lass die Straszen doch verbunden und setzt einfach ein access=no. Nur für das Übergangsstück oder die gesamte Trasse? Letzteres wäre etwas mühsam da es ja auch bei Inbetriebnahme wieder vollständig entfernt werden muss- mit der Unterbrechung kann ich leicht sicherstellen dass auch sehr einfache Router nich auf die Baustelle routen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Frederik Fischer fe...@studio-24.net wrote: http://wiki.openstreetmap.org/index.php/Cobra Die Downloads haben .rar Ist das nicht ein Archivformat einiger Linux-Distributionen? Etwas verwunderlich wo doch drueber steht, Cobra ziele vorrangig auf Windoof... ;-) Jedenfalls kann weder Vista noch mein cygwin darauf da was mit anfangen, also bleibt's Praesent erstmal unausgepackt... ;-) Dieses Cobra meinte ich. Mit Offset meine ich eine Projektion des Pfades um einen bestimmten Betrag nach rechts oder links. Eine einfache Translation w?rde ja, wie von dir erw?hnt, nicht ausreichen. ( http://osm.studio-24.net/images/cobra/path_offset.png ) Ja, sowas waere noetig fuer einseitiges... ( http://osm.studio-24.net/images/cobra/dev08091603.jpg ) Die DIskussionsseite klingt so, als waere das getrickst, oder verstehe ich da was falsch? ABer vermutlich meinst Du das, was auf der Cobra-Seite mit virtual ways bezeichnet wurde und das mit dem dy=0.4? Macht Cobra aus dem .osm dann trotzdem gueltiges SVG? In der Tat waere das dann ein Zuruecklassen der XSLT-Entwicklungslinie, die dann nicht mehr mit der orp-Linie kompatibel waere... Muessen die Osmarender-Erfinder entscheiden, ob das im Sinne Osmarenders ist... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Heiko Jacobs schrieb: Frederik Fischer fe...@studio-24.net wrote: http://wiki.openstreetmap.org/index.php/Cobra Die Downloads haben .rar Ist das nicht ein Archivformat einiger Linux-Distributionen? Was hat ein Fileformat mit 'nem Betriebssystem zu tun? Wenig. Deshalb google mal nach winrar. Grüße, Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] power-line/tower/sub_station
BroadwayLamb broadwayl...@gmx.net wrote: Ja gerne, aber nicht nur dunkler, sondern vor allem viel d?nner und als durchgehenden Strich - wie solche Kabel halt aussehen. Im jetzigen In Z16 ist's eigentlich duenn genug m.E., in Z17 habe ich es nun duenner gemacht, und die Strichlierung etwas geaender in 16 und 17, durchgehend traue ich mich noch nicht, find's strichliert eigentlich momentan noch besser... Zustand wundere ich mich immer ?ber den vermeintlichen (gestrichelten) Trampelpfad mitten durch die Pampa, der sich bei n?herem Hinsehen dann als power line herausstellt. ;) Wenigstens kannst Du mit Oberleitung laufend etwas weniger Muskelarbeit einsetzen? ;-) Danke ?brigens f?r die Pipelines. Gerne doch. Ich wollte ja auch nur meine gemappten Pipelines sehen ;-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Chris-Hein Lunkhusen schrieb: Heiko Jacobs schrieb: Frederik Fischer fe...@studio-24.net wrote: http://wiki.openstreetmap.org/index.php/Cobra Die Downloads haben .rar Ist das nicht ein Archivformat einiger Linux-Distributionen? Was hat ein Fileformat mit 'nem Betriebssystem zu tun? Wenig. Deshalb google mal nach winrar. Oder noch besser: google nach 7zip. Dann kannst du dir den Kauf von WinZip und Konsorten nämlich komplett sparen ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Moin On Fri, 23 Jan 2009, Ulf Lamping wrote: Garry schrieb: Das ist sicher eins der kleineren Problem die in openrouteservice noch angepasst werden müssten. Josm ist inzwischen angepasst (Version 1323) und zeigt construction=yes korrekt an. Das ist ja wohl eine Frechheit! Ich möchte dich bitten zu erwähnen, das ich diese Lösung extra für dich temporär in den Josm eingebaut habe und in etwa drei Monaten wieder rausnehmen wollte! schade eigentlich, ich finde ja construction=yes auch sinnvoller ... aber wenn die Anzeige in josm auf extra Bitten für kurze Zeit eingeführt wurde und dann so undiplomatisch versucht wird, diese Anzeige zu zementieren, dann muss ich wohl damit leben, dass diese schöne Variante wieder von dannen zieht, ohne dass ich überhaupt gemerkt habe, dass sie funktioniert ;-) (bitte jetzt nicht hier über Sinn und Unsinn von construction=yes streiten, ich kann ja auch damit leben, wenn andere Menschen das anders handhaben als ich und diese Edit-Wars finde ich sowieso dämlich - mit der Zeit erledigen sich glücklicherweise ca. 99,9 % der Streitfälle eh von selbst) seufz Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Andreas Labres l...@lab.at [Sat, Jan 24, 2009 at 05:12:43PM CET]: Torsten Leistikow wrote: Andreas Labres schrieb: Gibt's eigentlich kein amenity=gym oder leisure=gym für ein Fitness-Studio? *grübel* Es gibt ein leisure=sports_centre. Naja... daß ein Areal mit so ein paar Fußballplätzen oder ein Tennisclub ein sports_centre sein könnte, lasse ich mir ja noch einreden, aber ein Gym? Nachdem ich die Vorlagen unter JOSM benutzt habe, bin ich der Meinung, dass sports_centre überdacht ist im Gegensatz zu pitch. Denke ich da falsch? -- 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] Osmarender - cycleway-Darstellung
Am Samstag 24 Januar 2009 21:39:10 schrieb Heiko Jacobs: Die Downloads haben .rar Ist das nicht ein Archivformat einiger Linux-Distributionen? Was Du meinst ist .tar bzw .tar.gz Etwas verwunderlich wo doch drueber steht, Cobra ziele vorrangig auf Windoof... ;-) Jedenfalls kann weder Vista noch mein cygwin darauf da was mit anfangen, also bleibt's Praesent erstmal unausgepackt... ;-) WinRar hilft dir hier weiter: http://www.rarlabs.com/download.htm Gruß Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Moin nochmal, scheint ja wirklich wichtig zu sein, deshalb gebe ich jetzt hier doch noch mal einen Kommentar Wenn wir mal einen Großteil der Straßen erfasst haben, werden wir häufig den Fall haben, dass Straßen länger für eine Sanierungsphase gesperrt werden. Da ist es einfacher, kurz ein construction=yes einzufügen, denn schließlich bleibt es weiterhin (in den überwiegenden Fällen geht es ja um ein Fahrbahn-Reparatur) eine Bundes-, Landes- oder sonstige Straße. Wenn die Straßen im Bau sind, gilt das gleiche - es ist von vorneherein klar, was für ein Straßentyp gebaut werden soll (und auch, was für ein Kraftwerkstyp, für denjenigen, der da etwas auf der Leitung steht) - auch hier macht ein construction=yes Sinn. Den Renderer vorzuschieben, ist in meinen Augen Unsinn, ansonsten bitte das Don't tag for the renderer an entsprechender Stelle streichen - aber das will wohl keiner. Auch macht die Trennung von Objekttyp und Objektstatus sehr wohl Sinn, auch wenn dies teilweise etwas aufwändigeres Rechnen für das Rendern notwendig ist. Meiner Meinung nach gibt es hier also kein Argument in Sachen Renderer gegen construction=yes. Das der Renderer auf diese Lösung bis heute nicht eingeht, spielt schlicht gar keine Rolle - oder bestimmen jetzt die Programmierer der Renderer, welche Regeln gelten? Tsts, Regeln werden gerne so umgebogen wie man sie braucht, oder? Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
BroadwayLamb broadwayl...@gmx.net wrote: War da nicht mal eine ?nderung geplant? Nach meiner bescheidenen Meinung w?rde die Zahl in einem blassen Grau doch reichen, von mir aus auch noch mit einem d?nnen Ring au?en herum - quasi das Negativ der jetzigen Darstellung. Habe mal experimentiert in diese Richtung... Was ich aber ehrlich nicht ganz verstanden habe ist der Umstand, dass bei areas ein Symbol und bei nodes ein circle genommen wurde. Habe ersteres mal auskommentiert und durch letzteres ersetzt. Wahrscheinlich sitzt da jetzt was voellig daneben... ;-) Dann lasse ich mir was anderes einfallen. Also erstmal nur Hausnummern angucken, wo die Zahl im Kreis sitzt, weil's 'n node ist... ;-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Kann man die Nummern nicht einfach wie bei Google anzeigen? Müssen wir es unbedingt ANDERS machen? Ich finde, dass einfach die Zahl ausreicht, evtl. nicht schwarz sondern grau. ist ja durchaus auch bei anderen Plänen so finde ich genau richtig und besser als die Lösung bisher also: +1 :-) Schusch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging Schema mit Namespace was: Re: construction
Fabian -Patzi- Patzke openstreet...@patzi.de wrote: construction:highway=primary Einfach mal dr?ber nachdenken, evtl. ist es ja ein hilfreicher L?sungsansatz. Ich empfinde es momentan als ziemlich praktisch und logisch, aber vielleicht ?bersehe ich auch gerade Nachteile. Klingt nicht mal so schlecht... Sieht rueckwaertskompatibel aus, spart tags, ... Wird Garry trotzdem nicht gefallen, weil es sein Spezialproblem nicht loest. MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction - OT
Heiko Jacobs schrieb: Garry garr...@gmx.de wrote: Ich werde meine m?hsam erstellten Objekte weiterhin gegen Dich verteidigen das ich sie weiterhin vor Ort mit Mobilger?ten verfeinern kann. Einige dieser Objekte hast Du nicht muehsam erstellt und ein anderes Objekt wird nur ueber meine Leiche als existent gerendert, solange das noch nicht mal richtig geplant ist, geschweige denn, dass da die naechsten Jahre ueberhaupt eine Baumschine in der Naehe ist. Die Trasse befindet sich nach meinen Informationen im Raumordnungsverfahren und es ist kaum damit zu rechnen dass sie noch grossartig verändert wird. Wenn alle die gegen eine bestimmte Strasse/Brücke sind diese in OSM löschen bzw. unsichtbar machen würden bestünde OSM vermutlich bald nur noch aus Rad- und Fusswegen... Ist doch so, dass Du ein erklärter Gegner der 2.Karlsruher Rheinbrücke/Nordtangente bist um die es Dir hier eigentlich geht und sie deshalb nur über Deine Leiche auch nur als construction sehen willst, oder? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction - OT
Hallo Garry, beim besten Willen: construction=yes (oder wie auch immer) erst, wenn da auch wirklich physikalisch was passiert - also wenn eine erste Baustellenabsperrung da ist. Also erst, wenn du mit deinem GPS-Gerät auch wirklich an einen Ort fahren kannst, an dem dann auch wirlich das passiert, was du in die Karte einträgst ... wir sind doch kein Planungs- oder Baubüro. Und da ist es völlig egal wie man politisch zu dem Bauvorhaben steht. Gruß, Schusch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Garry garr...@gmx.de wrote: Garry sagt ja was von Garmin-Karten. Dazu fand ich mkgmap im Netz, vermutlich nimmt er das? Ich nehme die Karten von Computerteddy(f?r Garmin,TTQV), NaviPowm,... Hinter Computerteddys Karten steckt Mkgmap, wie seine Seite aussagt. und m?chte mir nicht einen eigenen Karten-Style basteln Soso... Du hast also Spezialinteressen (geplante und in Bau befindliche Straszen) und diesen Deinen Spezialinteressen muss sich die Allgemeinheit mit den allgemeinen Interessen (nutzbare Straszen) unterordnen und mit groben Fehlern in der Karte leben, weil Du Dich nicht um eine Spezialloesung kuemmern magst... sondern eine allgemeine Darstellung verwenden wie sie seit jeher auf Papierkarten ?blich ist - notfalls - falls die gestrichelte Darstellung nicht umgesetzt ist - mit einer entpsrechenden Beschriftung ?ber das name-Tag Papierkarten stellen in erster Linie die real existierenden Wege dar. In Bau befindliches wird oft gerendert, in Planung befindliches schon seltener, sicher nicht durchgaengig. Genauso ist es in OSM jetzt schon. Osmarender und Mapnik stellen in bau befindliche Straszen dar, so sie highway=construction construction=... getaggt werden. Andere sparens ich noch die Darstellung. Wenn ich mal den Papierkartenladen mit OSM vergleiche, dann ist Dein Wunsch in Topographischer Karte und Generalkarte als den im Papierkartenladen meistverkauften Karten, vulgo Mapnik und Osmarender als meistgenutzte OSM-Karten, Deinen Wuenschen entsprechend umgesetzt. Genauso wie im Papierkartenladen sicher eine seltene Kartenserie existiert, die das nicht darstellt, gibt's in OSM auch eine Karte, die das nicht darstellt. Pech, dass es gerade Deine Lieblingskarte ist... Wobei ich dort derzeit nichts finde, das darauf hin deutet, das Deine Straszen darin nun korrekt = in Bau oder so, dargestellt werden... Die Zahl der Werte bleibt dagegen bei beiden Modellen gleich highway=art status=yes und highway=status status=art sind jeweils immer 2 Nur dass man im ersten Fall eine saubere Trennung zwischen highway-Typ und Status hat und im zweiten Fall erst pr?fen muss ob es ein Status oder eine Strassenkategorie ist. Das kommt darauf an, ob man sich an der theoretischen oder praktischen Straszenkategorie orientiert. theoretisch mag eine Baustelle oder ein Federstrich auf der Karte (in Planung befindlich) eine Autobahn werden wollen, praktisch kann man darauf oeffentlich noch nicht Auto fahren, also ganz praktisch betrachtet die Strazenklasse construction oder planned. Fuer die theoretische Straszenklasse haben wir im uebrigen auch noch den tag ref=A98 oder so. MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern - Renderer
Heiko Jacobs heiko.jac...@gmx.de wrote: Wie es bei Mapnik laeuft, weisz ich noch nicht... Vor dem mapnik Style haben die Leute traditionell mehr Respekt. Einfach mal nen svn log anwerfen :) Bei den Osmarender Styles ist es eigentlich mehr oder weniger normal, dass man einfach macht. Deshalb hat mir auch kürzlich jemand die Flußbreiten verpfuscht. Sven -- This APT has Super Cow Powers. (apt-get --help on debian woody) /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] Hausnummern
Roland Spielhofer rsp...@gmx.net wrote: IIRC ist das prominente Rendering eingeführt worden, nachdem das Karlsruhe-Schema entwickelt wurde, um die Fortschritte hier gleich ganz drastisch sichtbar zu machen. Hintergedanke war wohl, wenn das Hausnummern-mappen einmal etabliert ist, die Sichtbarkeit wieder zurückzufahren. Im Mailinglisten-Archiv müsst man das nachlesen können. genau so war das gedacht! Sven -- Remember, democracy never lasts long. It soon wastes itself, exhausts and murders itself. There never was a democracy yet that did not commit suicide. (John Quincy Adams) /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] Hausnummern
Heiko Jacobs heiko.jac...@gmx.de wrote: Habe mal experimentiert in diese Richtung... Habs grade beim svn up gemerkt. Wirf die Kringel ganz weg! Sven -- In my opinion MS is a lot better at making money than it is at making good operating systems (Linus Torvalds, August 1997) /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] construction - OT
Garry garr...@gmx.de wrote: Die Trasse befindet sich nach meinen Informationen im Raumordnungsverfahren und es ist kaum damit zu rechnen dass sie noch grossartig ver?ndert wird. Nur auf pfaelzischer Seite gab es bisher ein Linienbestimmungsverfahren oder wie das dort heiszt, eine Vorstufe jedenfalls erst zu tiefergehenden Planungen. Die Trasse geht durch ein FFH-Gebiet, die hoechste Stufe des Naturschutzes. Es ist also fraglich, ob die Planung Bestand haben kann. Auf badischer Seite gibt es, wie an anderer Stelle erwaehnt, seitens des Karlsruher gemeinderats einen gueltigen Beschluss aus 2006 gegen diese Planung. Wenn alle die gegen eine bestimmte Strasse/Br?cke sind diese in OSM l?schen bzw. unsichtbar machen w?rden best?nde OSM vermutlich bald nur noch aus Rad- und Fusswegen... Ich hatte sher sie nicht geloescht, sondern nur so umgetaggt, dass sie in den Hauptanwendungen nicht falsch dargestellt wird und auch prinzipiell nicht fehlerhaft (construction) getagged ist. Osmarender wuerde sie so, wie ich sie getaggt habe, darstellen Ist doch so, dass Du ein erkl?rter Gegner der 2.Karlsruher Rheinbr?cke/Nordtangente bist um die es Dir hier eigentlich geht und sie deshalb nur ?ber Deine Leiche auch nur als construction sehen willst, oder? Die Bruecke ist nicht construction, sondern maximal planned. Die Nordtangente-Ost, die Du auch schon des oefteren so umgetaggt hast, dass sie als real existierend angezeigt wird, ist derzeit in construction und ich tagge sie genau so, dass sie so in Renderern und Routern verwendet wird. Ich tagge korrekt unabhaengig von meinen politischen Ansichten zu dieser Strasze oder anderen. Unkorrektes tagging von strittigen Hirngespinsten aber nur ueber meine Leiche... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Johannes Huesing johan...@huesing.name wrote: Nachdem ich die Vorlagen unter JOSM benutzt habe, bin ich der Meinung, dass sports_centre überdacht ist im Gegensatz zu pitch. Wie Bitte? sports_centre wird AFAIK grün gerendert! 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] Osmarender - cycleway-Darstellung
Ulf Lamping ulf.lamp...@googlemail.com wrote: Chris-Hein Lunkhusen schrieb: Heiko Jacobs schrieb: Frederik Fischer fe...@studio-24.net wrote: http://wiki.openstreetmap.org/index.php/Cobra Die Downloads haben .rar Ist das nicht ein Archivformat einiger Linux-Distributionen? Was hat ein Fileformat mit 'nem Betriebssystem zu tun? Weisz nicht. Mir ist, meine ich, bisher nur dort fluechtig begegnet... Wenig. Deshalb google mal nach winrar. Hmmm... Sieht nach Kosten aus... Oder noch besser: google nach 7zip. Dann kannst du dir den Kauf von WinZip und Konsorten n?mlich komplett sparen ... Sieht schon besser aus... ;-) Irgendein Zip ist bei meinem Vista schon eingebaut oder so. Fiel mir dadurch unangenehm auf, weil es saulangsm auspackt... Da rufe ich doch lieber eine cygwin-Konsole auf und darin unzip ...;-) So, 7--zip laeuft, cobra entpackt, nun ein wenig damit spielen :-) Danke fuer die Tipps! MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging Schema mit Namespace was: Re: construction
Fabian -Patzi- Patzke schrieb: Hallo, wäre nicht auch bei der highway=construction vs. construction=yes Problematik eine Lösung ein namespace tagging einzuführen. Man hätte dann: construction:highway=primary Das scheint mir momentan die geeignetste Kompromisslösung zu sein. Es verhindert, dass ein argloser Renderer das Objekt als existent ansieht, erlaubt aber auch, mehrere Tags an einem Objekt auszublenden, wo nötig, und ist intuitiver (und fühlt sich weniger wie ein Hack an) als highway=construction. Von der Idee her ist es eine Variante des Eintrags key-status = value in der Übersicht http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts mit anderer Syntax. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten in JOSM einblenden
Hallo, Claudius Henrichs wrote: 1.) Mithilfe des Metacarta Mac Rectifiers referenzierst du dein Bildmaterial mit Geokoordinaten: http://labs.metacarta.com/rectifier/ Das hier ist angeblich besser als der Map Rectifier: http://wrp.geothings.net Und man kann den Source runterladen (MIT-Lizenz). 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] Vorschläge zur öonvkarte.de
Gerrit Lammert o...@00l.de writes: Ich packe alle Haltestellen mit in die relation der Route. ich meine das auch irgendwo als Standard gelesen zu haben. Das gefällt mir nicht. Ich würde eine relation für die strecke (route) und eine für die haltestellen (stops/halts) machen und beides dann über eine weitere relation (line) verbinden. Die dinge bleiben dann übersichtlicher. Leider haben wohl auch schon einige angefangen, in hiking-routen zeug zu stecken, dass am weg liegt und im zusammenhang mit wandern irgendwie interessant sein könnte... -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Center
Sven Geggus wrote: Johannes Huesing johan...@huesing.name wrote: Nachdem ich die Vorlagen unter JOSM benutzt habe, bin ich der Meinung, dass sports_centre überdacht ist im Gegensatz zu pitch. Wie Bitte? sports_centre wird AFAIK grün gerendert! Ich hab eigentlich grundsätzlich ein Verständnisproblem beim sports_centre... Meine Vorstellung wäre, daß eine Sportanlage, wo so mehrere Fußballfelder nebeneinander liegen, oder ein Tennisverein mit einem Haufen Plätzen ein sports_centre ist. Dem widerspricht aber, daß sports_centre genauso dunkelgrün gerendert wird wie pitch (Mapnik), sprich mehrere pitches innerhalb eines sports_centre einfach verschwinden. Auch Gebäude sind auf der dunkelgrünen Fläche kaum sichtbar. Also: entweder versteh' ich sports_centre falsch oder es wird falsch gerendert (Mapnik). Wäre interessant, was sich der Erfinder ursprünglich gedacht hat... Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschläge zur öpnvkarte.de
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ach ja, das Gelb für Train geht ziemlich unter auf der Karte. Und seit wenn soll (so das wiki) die S-Bahn als rail und nicht als light_rail gemappt werden??? - -- Gruß Mario -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl8B5EACgkQdRpju1J3VHFq1wCZAaG06ahaK1Ygy/925QqIdSe/ Sb4An03gYvWH1wRXIJM3GrGiM7Geoaj1 =C1vM -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender - cycleway-Darstellung
Hallo. Am Samstag, 24. Januar 2009 schrieb Heiko Jacobs: Die Downloads haben .rar Ist das nicht ein Archivformat einiger Linux-Distributionen? Nein, rar ist das gängige Archivformat der bösen Warez-Tauscher. :) Gruß, Bernd -- Schade, daß rote Zahlen auf dem Konto nicht annähernd so beruhigend sind wie auf dem Kalender. 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
