[Talk-de] addr:phone vs. phone
Am 6. Februar 2010 13:01 schrieb Mirko Küster webmas...@ts-eastrail.de: Am 06.02.2010 12:42, schrieb Harald Schwarz: Ich finde hier kann man mal Adressdaten vereinheitlichen und sollte in Zukunft dafür allgemein addr:* einsetzen. Und für die Zukunft wäre das addr:* Schema viel besser. Die form mit addr: davor ist mir in der Praxis noch nie unter gekommen, ist glaube ich auch garnicht dokumentiert. Anders phone, fax, email, die ich so auch nutze. Welchen Vorteil versprichst du dir durch verwendung von addr:phone anstatt von phone? Zumal eine Telefonnummer nichts mit einer Anschrift zu tun hat, wofür das Schema entwickelt wurde. Eine Telefonnummer kann auch mal unabhängig von einer Adresse auftauchen, bspw. bei einem Audioguide oder als Informationshotline. Ich bin der Meinung, man sollte addr:* nicht sinnlos erweitern, nur damit die Kontaktdaten alle bei einander stehen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenlistenabgleich - jetzt in Selbstbedienung
Hallo, Sven Anders wrote: wenn du mein neues Polygon eingespielt hast, sollte das jetzt nicht mehr so sein, hab das aber noch nicht validiert. Hab ich schon vor ner Woche oder so! Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschte line-Relationen
Hallo! Florian Gross schrieb: Wolfgang Wienke glaubte zu wissen: Hallo, ich hatte nach dem OXOMOA-System Busrouten gemapt und finde jetzt plötzlich die line-Relationen nicht mehr. Sie sind auch in den Routenrelationen nicht mehr als Elternrelationen enthalten. Muss die jemand gelöscht haben, oder kann das an Problemen des OSM-Servers liegen? Einen Zugriff auf http://www.openstreetmap.org/browse/relation/ wird bei mir nämlich mit file not found bearbeitet. Weißt du die Nummer der Relation noch? Wenn ja, hast du evtl. mit http://osm.cdauth.de/history-viewer/ etwas mehr Erfolg. Danke, ich habe sie jetzt dort gefunden. Anscheinend arbeite JOSM plötzlich anders. Elternrelationen werden in der Child-Relation nicht mehr automatisch angezeigt und mit herunter geladen. Erst wenn man im Relationseditor unter Eltern-Relation neu Laden anklickt, werden diese geladen!!! Warum macht man solcher verwirrende Änderungen? -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMS unter MAC OSX 10.6
Hi, bei mir half ja Folgendes: 1) QT laden und installieren (s. Mail thread) 2) webkit-image binary laden http://josm.openstreetmap.de/download/macosx/ und ablegen unter /usr/bin/webkit-image (wenn ihr nicht wisst, wie das geht: Terminal aufmachen, dann vom Ort, sagen wir /Users/donaldduck/Downloads verschieben mit: sudo cp /Users/donaldduck/Downloads/webkit-image /usr/bin sudo chmod +x /usr/bin/webkit-image beim ersten sudo-Befehl muss man das Kennwort des Administrators eingeben (damit es als super user läuft...). ) Dann klappts bei mir auch ohne kompilieren. Der Trick: webkit-image ist dann im Suchpfad und QT wird auch gefunden... Gruß, Werner Am 07.02.10 01:16, schrieb Stefano Kowalke: Am 07.02.10 00:35, schrieb FlaBot: JOSM-Plugin-WMS Mac OS X Prerequisites * Install XCode (free download from Apple after regstration, see http://developer.apple.com/mac/) * Install Qt SDK (free download from Qt Software, see http://www.qtsoftware.com/downloads/ “LGPL Downloads”, “Download Qt SDK for Mac”) Ah, stimmt ohne dieses Zeug läuft es nicht. Da man das zum kompilieren eh braucht hatte ich das gar nicht mehr auf dem Schirm. Stefano ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation wird nicht angezeigt
Wenn IE Standard-Einstellung für die Sicherheit benutzt werden, geht es in der Tat nicht. Lösung: Die Domain www.openstreetmap.org zu den Trusted Sites hinzufügen. Warum das Problem aber in erster Instanz auftritt kann ich auch nicht sagen. Gruß R.L. - Original Message - From: Jochen Plumeyer To: talk-de@openstreetmap.org Sent: Saturday, February 06, 2010 6:14 PM Subject: Re: [Talk-de] Relation wird nicht angezeigt Moin nochmal, On Sáb 06 Feb 2010, Tirkon wrote: Meldung: Unbekannter Fehler. Zeile: 483 Zeichen: 208 Code: 0 URI: http://www.openstreetmap.org/openlayers/OpenLayers.js?1251388304 Geht nicht auf Windows7. Identische Fehlermeldung auf Windows7 und IE 8, bei aktiviertem Schutzmodus. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Content Policy Scan by M+ Guardian Millions of safe clean messages delivered daily ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschte line-Relationen
Wolfgang Wienke schrieb am 07.02.2010 10:40: Danke, ich habe sie jetzt dort gefunden. Anscheinend arbeite JOSM plötzlich anders. Elternrelationen werden in der Child-Relation nicht mehr automatisch angezeigt und mit herunter geladen. Erst wenn man im Relationseditor unter Eltern-Relation neu Laden anklickt, werden diese geladen!!! Warum macht man solcher verwirrende Änderungen? Da war ich kuerzlich auch drueber gestolpert (siehe meine Mail vom 03.02.). Das interessante dabei ist, dass ich nicht mal eine neue JOSM-Version benutze. trotzdem habe ich auf ein Mal ein anderes Verhalten; merkwuerdig. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Hallo zusammen, danke für eure Hinweise. Ich werde nochmal darüber nachdenken. Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wenn unter Adresse nur Informationen verstanden werden, mit denen ein Objekt lokalisiert bzw. per Brief angeschrieben, also adressiert werden kann, dann passen natürlich obige Kontaktinformationen nicht ins addr:* Schema. Es hängt also ganz davon ab, welchen Blick man auf eine Adresse wirft um zu entscheiden was ins Schema gehört und wie man es tagt. Mit freundlichen Grüßen Harald Schwarz OSM: black_bike OSM-Wiki: BlackBike Original-Nachricht Datum: Sun, 7 Feb 2010 09:10:53 +0100 Von: André Riedel riedel.an...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: [Talk-de] addr:phone vs. phone Am 6. Februar 2010 13:01 schrieb Mirko Küster webmas...@ts-eastrail.de: Am 06.02.2010 12:42, schrieb Harald Schwarz: Ich finde hier kann man mal Adressdaten vereinheitlichen und sollte in Zukunft dafür allgemein addr:* einsetzen. Und für die Zukunft wäre das addr:* Schema viel besser. Die form mit addr: davor ist mir in der Praxis noch nie unter gekommen, ist glaube ich auch garnicht dokumentiert. Anders phone, fax, email, die ich so auch nutze. Welchen Vorteil versprichst du dir durch verwendung von addr:phone anstatt von phone? Zumal eine Telefonnummer nichts mit einer Anschrift zu tun hat, wofür das Schema entwickelt wurde. Eine Telefonnummer kann auch mal unabhängig von einer Adresse auftauchen, bspw. bei einem Audioguide oder als Informationshotline. Ich bin der Meinung, man sollte addr:* nicht sinnlos erweitern, nur damit die Kontaktdaten alle bei einander stehen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation wird nicht angezeigt
LongRed long...@myrealbox.com wrote: Wenn IE Standard-Einstellung für die Sicherheit benutzt werden, geht es in der Tat nicht. Lösung: Die Domain www.openstreetmap.org zu den Trusted Sites hinzufügen. Wenn eine stinknormale Anzeige der Karten schon nicht funktioniert, wäre es dann im Sinne von Otto Normalsurfer nicht sinnvoll, wenn sich die OSM-Foundation grundsätzlich darum bemühen würde? Ich weiß allerdings nicht, ob so etwas überhaupt bei Microsoft (oder wer auch immer dafür zuständig ist) beantragt werden kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wir sammeln Geodaten. Adressen sind eigentlich fest an Grundstücke oder Gebäudeteile vergebene Merkmale. Geplante aber unbebaute Grundstücke haben auch fest vergebene Adressen, die wir hier allerdings nicht hinterlegen. Sehen oder wissen wir ja meistens sowieso nicht und wir verwalten die ja nicht sondern pflegen den aktuell vorhandenen Bestand. Unsere Möglichkeiten geben es aber schlicht nicht her ein Grundstück zu definieren, dem als Member die Gebäude und darunter wiederum die einzelnen Nutzer als Gruppen anzulegen. Deswegen machen wir für alles einen POI und da muss dann jedesmal extra die Adresse dazu oder der POI irgendwie verknüpft werden. Kontaktdaten sind kein Bestandteil der eigentlichen Adresse, das sind frei wählbare Kontaktmöglichkeiten eines einzlenen Nutzers oder einer Sache, die vollkommen unabhängig von Adressen laufen. Auch Gegenstände oder Nutzer ohne Adresse können einen Kontakt haben. Automaten, Imbissstände, Informationsangebote... Kontaktdaten passen daher nicht wirklich ins Adressschema. Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Da wo es nicht nötig ist brauchts keine unnötig aufblähten und verkomplizierten Tags. Vor allem wenn diese dann derzeit ohne Editorunterstützung auskommen muss und wieder dutzende Tippfehler ansaugt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschte line-Relationen
Am 7. Februar 2010 11:51 schrieb Torsten Leistikow de_m...@gmx.de: Wolfgang Wienke schrieb am 07.02.2010 10:40: Danke, ich habe sie jetzt dort gefunden. Anscheinend arbeite JOSM plötzlich anders. Elternrelationen werden in der Child-Relation nicht mehr automatisch angezeigt und mit herunter geladen. Erst wenn man im Relationseditor unter Eltern-Relation neu Laden anklickt, werden diese geladen!!! Warum macht man solcher verwirrende Änderungen? Da war ich kuerzlich auch drueber gestolpert (siehe meine Mail vom 03.02.). Das interessante dabei ist, dass ich nicht mal eine neue JOSM-Version benutze. trotzdem habe ich auf ein Mal ein anderes Verhalten; merkwuerdig. Wahrscheinlich hängt auch dieser Fehler oder diese Verändeung mit dem Wechsel der API auf dem OSM-Server zusammen. http://lists.openstreetmap.org/pipermail/talk-de/2010-February/062703.html Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Mirko Küster webmas...@ts-eastrail.de [Sun, Feb 07, 2010 at 02:02:46PM CET]: [...] Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Hab jetzt nicht nachgeschaut, ob das vorkommt, aber was würde man bei phone=* im Zusammenhang mit amenity=phone erwarten? Die Nummer einer anrufbaren Telefonzelle, die Nummer der zugehörigen Störungsstelle, oder eine nähere Beschreibung des Telefons (ähnlich wie natural=wetland, wetland=marsh)? -- 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] Wiki: Skipisten
Markus-2 wrote: http://openpistemap.org/?lat=49.64079lon=11.39781zoom=17layers=B000 Da gibts weder Skilift noch Loipe. Das ist der Spieser Skilift - den gibt's definitiv. -- View this message in context: http://n2.nabble.com/Wiki-Skipisten-tp4526002p4529653.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Mirko Küster webmas...@ts-eastrail.de [Sun, Feb 07, 2010 at 02:02:46PM CET]: [...] Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Hab jetzt nicht nachgeschaut, ob das vorkommt, aber was würde man bei phone=* im Zusammenhang mit amenity=phone erwarten? Die Nummer einer anrufbaren Telefonzelle, die Nummer der zugehörigen Störungsstelle, oder eine nähere Beschreibung des Telefons (ähnlich wie natural=wetland, wetland=marsh)? Was du da erwartest weiß ich nicht. Ich würde darunter die Nummer einer anrufbaren Zelle verstehen, da phone nunmal für die Telefonnummer steht. Für einen Spezialfall wie Telefonzelle muss man dann mit Zusatzangaben entsprechend abgrenzen. service:phone Störung, emergency:phone Notruf etc. Da hat sich noch keiner weiter Gedanken gemacht. Bei der Telefonzelle hat man es sich aber auch wieder zu einfach gemacht. Eigentlich sind das ja call box, telephone booth, telephone box, phone box. Während man nur phone ja eigentlich normal im contact nutzt. Das ist wieder so eine unnötige hausgemachte Überschneidung. Ansonsten hast du genauso wie bei access die gleiche Grütze. Neutrale einfache Tags wie bicycle=yes, die sich eigentlich schön global einsetzen lassen, für den einen Spezialfall wie eben access auf ewig festgenagelt. Dafür muss man dann jeglicher anderen Verwendung wieder einen extra Namensraum verpassen oder gar einen ganz neuen Tag erfinden. Extrem häßlich, aber wohl nicht mehr zu ändern. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 7. Februar 2010 14:02 schrieb Mirko Küster webmas...@ts-eastrail.de: Unsere Möglichkeiten geben es aber schlicht nicht her ein Grundstück zu definieren, dem als Member die Gebäude und darunter wiederum die einzelnen Nutzer als Gruppen anzulegen. ach so? Unsere Möglichkeiten geben das nicht her? Kann man mit Relationen doch problemlos machen. Auch Gegenstände oder Nutzer ohne Adresse können einen Kontakt haben. Automaten, Imbissstände, Informationsangebote... Kontaktdaten passen daher nicht wirklich ins Adressschema. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten
Am 06.02.2010 18:00, schrieb Max Andre: Hi! Es gibt in der Wiki schon seit ewigen Zeiten ein proposal für das Tagging von Skipisten [1]. Mit dem Proposal lässt sich definitiv sehr gut arbeiten und taggen. Ich nutze es seit über einem Jahr in verschiedenen Skigebieten. Eine Erweiterung (die sich dort noch nicht findet) habe ich auch für meine Ergänzungen übernommen: Das Pistenlayout als area zu taggen um die Pisten realistischer abzubilden (insbesondere deren unterschiedliche Breite und die Bereiche, die mit Einzellinien sehr unübersichtlich werden). Ich sehe das Feature ebenfalls als durch die Praxis angenommen. Man sollte zudem diesen Ansatz nicht mit Openpistemap gleichsetzen, ansonsten würde man die grafische Umsetzung von Osmarender mit OSM an sich gleichsetzen. Die Renderengines können aber immer nur einen Teil (als Kompromiss) abbilden. So lassen sich mit den derzeitigen Daten für Garmin-GPS sehr gut nutzbare Pistenkarten generieren, die denen kommerzieller Anbieter kaum nachstehen (und selbst Routing-Funktionen könnte man wohl realisieren). Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
ach so? Unsere Möglichkeiten geben das nicht her? Kann man mit Relationen doch problemlos machen. Ihr und eure Relationen... kompliziert, von vielen gemieden und alles andere als die ultimative Lösung für alles. Ja ich kann eine Site für ein Grunstück anlegen, und ja, ich kann dann eine Buildung machen. Das kann ich schön verschachteln. Ist aber sowas von anfällig und für viele zu kompliziert. Editorunterstützung garnicht bis kompliziert. Mit solchen Konstrukten nagelst du dir einen enormen Pflegeaufwand an die Backe. Ich würde da gerne einen anderen Weg gehen. Tag Set oder Group am Objekt selbst. Hauptobjekt Buildung mit seiner Adresse und vielleicht anderen Angaben und darunter für jeden Nutzer ein Set. Das erbübrigt dutzende Redundanzen und Einzelnodes, sowie Semikolonorgien, die sich maschinell auch nicht mehr Ordnen lassen und von der korrekten Eintragsreihenfolge des Nutzers abhängen. Im Set hast du das Problem nicht. Da kannst du meinetwegen das Set amenity=bank und das Set amenity=post_office als Postagentur in einem Objekt haben, beides jeweils mit seinen eigenen Angaben und ohne Überschneidungen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten
Hi Klaus, http://openpistemap.org/?lat=49.64079lon=11.39781zoom=17layers=B000 Da gibts weder Skilift noch Loipe. Das ist der Spieser Skilift - den gibt's definitiv. :-) In der Wirklichkeit und in der DB, aber nicht in der Karte. Nicht mal in der Piste--Map... Auch Loipen erscheinen nicht in der Piste-Karte. Für Skitouren habe ich im Wiki nichts gefunden (en: Ski touring) Überhaupt scheint /der OSMer/ wenig Wintersport zu betreiben: die mir bekannten Skiorte sind recht dürftig kartografiert. Weder Bars noch Hotels ;-) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 7. Februar 2010 17:10 schrieb Mirko Küster webmas...@ts-eastrail.de: ach so? Unsere Möglichkeiten geben das nicht her? Kann man mit Relationen doch problemlos machen. Ihr und eure Relationen... kompliziert, von vielen gemieden und alles andere als die ultimative Lösung für alles. dann schreib doch bitte nicht, dass _unsere_ Möglichkeiten das nicht hergeben. Ja ich kann eine Site für ein Grunstück anlegen, und ja, ich kann dann eine Buildung machen. Das kann ich schön verschachteln. Ist aber sowas von anfällig und für viele zu kompliziert. Editorunterstützung garnicht bis kompliziert. Du übertreibst m.E. maßlos: was soll an der Relation kompliziert sein? Die Zugehörigkeit wird an jedem Objekt angezeigt. Mit solchen Konstrukten nagelst du dir einen enormen Pflegeaufwand an die Backe. wieso? Von selbst geht das nicht kaputt... Ich würde da gerne einen anderen Weg gehen. Tag Set oder Group am Objekt selbst. Hauptobjekt Buildung mit seiner Adresse und vielleicht anderen Angaben und darunter für jeden Nutzer ein Set. Das erbübrigt dutzende Redundanzen und Einzelnodes, sowie Semikolonorgien, die sich maschinell auch nicht mehr Ordnen lassen und von der korrekten Eintragsreihenfolge des Nutzers abhängen. Im Set hast du das Problem nicht. Da kannst du meinetwegen das Set amenity=bank und das Set amenity=post_office als Postagentur in einem Objekt haben, beides jeweils mit seinen eigenen Angaben und ohne Überschneidungen. Soll das dann auch wieder mit Relationen gemacht werden, oder was sind diese sets? Das ist doch Schnee von Morgen, davon höre ich zum ersten Mal, und weder Editoren noch API verstehen das. Wieso das einfacher oder überhaupt was anderes als ne Relation sein soll, ist mir auch nicht klar geworden. Übrigens, (das schreibe ich Dir nicht zum ersten Mal), ist das Hauptobjekt das Grundstück (zumindest hat das die Adresse), und nicht das Gebäude. Das Gebäude ist Teil des Grundstücks. Von daher sollte es eigentlich ganz einfach sein: Siterelation, Grenze ist das Grundstück, dieses erhält die Adresse, darauf liegen die Gebäude (mit ggf. Adresszusätzen die nur gebäudeweise gelten) und die Nutzungen (oder, wenn man es gerne kompliziert hat: die Nutzungen in den Gebäuden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Du übertreibst m.E. maßlos: was soll an der Relation kompliziert sein? Die Zugehörigkeit wird an jedem Objekt angezeigt. Für dich ist das nicht kompliziert. Aber wie oft laufen Leute auf für die das nicht so ist, die Relationen meiden oder unbewusst kaputt machen? Aktuell haben wir doch wieder mal verschwundene Relationen auf der Liste. wieso? Von selbst geht das nicht kaputt... Doch, wenn irgendwein Tool Mist baut. Ansonsten braucht bloß einer einen Weg teilen, den Dialog nicht verstehen und wieder hats einen Fehler. Relationen fliegen einem permament um die Ohren. Ein Horror wenn jedes Gebäude eine hätte. Da bist du mehr mit fixen als mit anlegen beschäftigt. Ich habe vor einem halben Jahr aufgehört zu zählen, wie oft beispielsweise Busrelationen kaputt gingen. Soll das dann auch wieder mit Relationen gemacht werden, oder was sind diese sets? Das ist doch Schnee von Morgen, davon höre ich zum ersten Mal, und weder Editoren noch API verstehen das. Wieso das einfacher oder überhaupt was anderes als ne Relation sein soll, ist mir auch nicht klar geworden. Eben keine Relationen die wieder als eigenes Objekt dutzende andere Objekte mit Rollen zusammen kitten. Genau das solls nicht sein. Objekte wie jetzt auch, nur vom editor unterstützt die Möglichkeit ein eigenes Set oder Schachtel ins Objekt bringen. Nehmen wir als Vergleich einen Osmarender Style. Der hat eine Hauptschachtel die grob den Hauptag beschreibt. Darunter jeweils eine eigene Schachtel für jeweilige Defintionen die aber so immer in Verbindung mit Hauptobjekt bleibt. Im Moment geht pro Nutzung immer nur eine einzige Schachtel. So könntest du alles in einem Objekt halten, hast keine Überschneidungsprobleme mit gleichen Tags und brauchst auch keine zusätzlichen virtuellen Objekte wie Relationen. Haus Adresse +Set 1 Bank Kontakt etc. +Set 2 Post Bank Kontakt etc. Klar wird das noch nicht unterstützt. Man ruht sich ja noch auf den Beschränkungen und den Relationen aus. Das muss man erstmal audkaspern. Übrigends ist die Idee auch nicht neu. Kam früher schonmal und andere haben auch schon in der Richtung nachgedacht. Übrigens, (das schreibe ich Dir nicht zum ersten Mal), ist das Hauptobjekt das Grundstück (zumindest hat das die Adresse), und nicht das Gebäude. Das Gebäude ist Teil des Grundstücks. Erstens schreibe ich dir zum 1000 male das ich das weiß und zweitens interessiert das jetzt garnicht. Der Normale Mapper ist froh wenn er ein Gebäudepolygon zusammen hat. In Grundstücken braucht man in der Breite noch nicht zu denken. Das machst du, ich machs auch, vielleicht noch zehn oder zwanzig andere. Die Masse packt es mangeles besserer Daten ans Haus oder einen Node. Von daher sollte es eigentlich ganz einfach sein: Siterelation, Grenze ist das Grundstück, dieses erhält die Adresse, darauf liegen die Gebäude (mit ggf. Adresszusätzen die nur gebäudeweise gelten) und die Nutzungen (oder, wenn man es gerne kompliziert hat: die Nutzungen in den Gebäuden). Es ist für die breite Anwenderschaft eben alles andere als leicht. Es hat schon Seltenheitswert, wenn ich mal auf so eine Realtion stoße. Die Masse legt einfach Einzelobjekte. Ich nutze das auch nicht. Ich sehe wie andere Relationen permanent kaputt gehen. Solange das nicht sicherer wird oder eben eine andere Lösung kommt, mache ich einen Bogen darum. Verhunzte Objekte habe ich schnell wieder aus dem Backup geholt oder zurückgestellt. Bei Relationen ist es bei jeder einzelnen ne schöne Bastelarbeit. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues von der Reit- und Wanderkarte
-Original Message- From: talk-de-boun...@openstreetmap.org [mailto:talk-de- boun...@openstreetmap.org] On Behalf Of NopMap Sent: venerdì 5 febbraio 2010 0.42 To: talk-de@openstreetmap.org Subject: Re: [Talk-de] Neues von der Reit- und Wanderkarte Ja. Die Karte besteht aus 3 Layers, die nur zusammen gut aussehen. Mir ist noch kein Grund eingefallen, warum man die ein- und ausschalten mte. :-) bye Nop Manchmal ist nun die Karte im Hochgebirge zu dunkel, z.B.: http://topo.geofabrik.de/?lon=9.2495lat=45.8508zoom=15 Gruß Alberto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten
Markus schrieb: Überhaupt scheint /der OSMer/ wenig Wintersport zu betreiben: die mir bekannten Skiorte sind recht dürftig kartografiert. Weder Bars noch Hotels ;-) Das liegt sicher daran, dass man beim Skifahren schlecht mappen kann. Zum einen hat man die Hände voller Skistöcke, zum anderen müsste man, um POIs zu setzen, dauernd anhalten (und evtl auch die Handschuhe ausziehen). Auf meiner bisher einzigen Tour in diesem Winter bin ich halbwegs untrainiert 25 km entlang eines Kunstgrabens gefahren. *ächz* Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten
Am 07.02.2010 19:37, schrieb malenki: Markus schrieb: Überhaupt scheint /der OSMer/ wenig Wintersport zu betreiben: die mir bekannten Skiorte sind recht dürftig kartografiert. Weder Bars noch Hotels ;-) Das liegt sicher daran, dass man beim Skifahren schlecht mappen kann. Zum einen hat man die Hände voller Skistöcke, zum anderen müsste man, um POIs zu setzen, dauernd anhalten (und evtl auch die Handschuhe ausziehen). Ne, dass kann man schon machen. Einfach den Logger an den Rucksack binden und losfahren ;) Dabei kommt dann sowas bei raus. [1] Und Bilder kann man beim Skifahren auch. [2] Grüße Max [1] http://www.openstreetmap.org/user/telegnom/traces/616342 [2] http://openstreetview.org/?lat=47.214002429496lon=10.939445793197zoom=15 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMS unter MAC OSX 10.6
Ich ergänz mal deine Mail von Werner, um ein paar Erfahrungen, die ich in der letzten Zeit gemacht habe; Ich habe: 1) QT SDK installiert http://qt.nokia.com/downloads/sdk-mac-os-cpp 2) XCode von meiner SystemCD installiert 3) webkit-image binary geladen (Danke an Stefano!!) Den Alternativweg mit TinkerTool.app gewählt und webkit-image im HOME Ordner - Ordner .bin wie unten beschrieben untergebracht... (Alternative dazu (für alle die sich nicht ans Terminal trauen, so wie ich...): Das Freeware Programm TinkerTool.app ( http://www.macupdate.com/info.php/id/5721) downloaden: dann starten und dort in den Finder-Einstellungen: Versteckte und Systemdaten anzeigen anklicken - Finder neu starten - im HOME Ordner (das ist der mit dem Häuschen als Logo) nachsehen ob dort ein grauer Ordner .bin rumliegt, wenn nicht neuen Ordner erstellen und .bin benennen. (wichtig ist der Punkt davor!!). - In diesen Ordner einfach das webkit-image legen. Fertig. Wichtig dann in TinkerTool.app die Einstellungen: Versteckte und Systemdaten anzeigen wieder ausschalten und den Finder neu starten. (sollte der Finder hängen bleiben, dann im Dock doppelklicken, der kommt schon wieder...) Effekt leider der gleiche wie vorher: WMS startet das Abrufen von Daten aus dem Netz, im Dock arbeitet webkit-image, aber JOSM zeigt mir nichts davon, weder yahoo noch eine anderes WMS läuft. Hab schon gedacht es liegt daran, dass evtl für Unterfranken keine Bilder vorhanden sind, darum hab ich's mal mit Frankfurt/Main probiert... gleiches Ergebnis. NICHTS... Frage: Wie weiß JOSM nach der Systeminstallation, wo QT SDK und wo XCode liegen? Gruß UMAX974 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten
Max Andre schrieb: Am 07.02.2010 19:37, schrieb malenki: Das liegt sicher daran, dass man beim Skifahren schlecht mappen kann. Zum einen hat man die Hände voller Skistöcke, zum anderen müsste man, um POIs zu setzen, dauernd anhalten (und evtl auch die Handschuhe ausziehen). Ne, dass kann man schon machen. Einfach den Logger an den Rucksack binden und losfahren ;) Bis er einfriert? *hust* :) Dabei kommt dann sowas bei raus. [1] Und Bilder kann man beim Skifahren auch. [2] Hab ja ned gesagt, dass es nicht geht¹, nur ist es etwas umständlicher als beim Radfahren - das klappt über längere Zeit auch einhändig prima. ¹ http://openstreetview.org/?lat=50.804592250636lon=13.318068980637zoom=16 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten
Am 07.02.2010 21:09, schrieb malenki: Max Andre schrieb: Am 07.02.2010 19:37, schrieb malenki: Das liegt sicher daran, dass man beim Skifahren schlecht mappen kann. Zum einen hat man die Hände voller Skistöcke, zum anderen müsste man, um POIs zu setzen, dauernd anhalten (und evtl auch die Handschuhe ausziehen). Ne, dass kann man schon machen. Einfach den Logger an den Rucksack binden und losfahren ;) Bis er einfriert? *hust* :) Tja, das Backup hat gehalten ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM SVN-Script
Hallo, da ich keine Lust mehr hatte mir die neueste JOSM Version händisch auszuchecken und zu kompilieren habe ich mir ein Script für diesen Zweck gebaut. Das Script prüft erst ob die SVN-Version neuer ist als die Lokale. Wenn nicht wird die lokale Version gestartet. Wenn ja wird die aktuelle Version ausgecheckt und kompiliert. Falls das Repository nicht erreichbar ist versucht das Script die lokale Version zu starten. Sollte keine lokale Version vorhanden sein, beendet sich das Script. Wer Interesse daran hat kann es bei github [1] finden. Ich bin für jegliche Kritik und Anregungen offen... also immer her damit ;) Grüße Max [1] http://github.com/telegnom/JOSM-SVN-Updater ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OpenStreetMap // OpenCritics
Hallo liebe OpenStreetMap-er, ich fand' die OpenStreetMap-Idee schon immer faszinierend - und nachdem ich unlängst in Hamburg auf dem Stammtisch war, hatte ich eine Idee, wie man eventuell ein Projekt von uns mit OpenStreetMap verknüpfen könnte. Natürlich habe ich keine Ahnung, inwiefern bei OpenStreetMap sowieso schon in dieser Richtung entwickelt wird. Um das Verständlich zu machen, muss ich zunächst unser Projekt vorstellen: Die Bedeutung freier/frei lizenzierter Informationen für ein freies Internet hier darzustellen wäre wohl Eulen nach Athen tragen. :) Unser Ziel ist es nun, den Siegeszug des OpenContent bei Informationen (Wikipedia, OpenStreetMap ...) bei subjektivem Content in Form von Nutzerbewertungen/Kritiken fortzusetzen. Daher haben wir OpenCritics.de ins Leben gerufen. OpenCritics.de möchte einen kleinen Beitrag dazu leisten, dass auch mehr Nutzerbewertungen frei lizenziert werden. Über das OpenCritics - Netzwerk abgegebene Bewertungen stehen nicht nur den Besuchern von einzelnen Seiten wie Amazon oder Ciao etc zur Verfügung sondern dürfen frei kopiert werden. Dies beugt auch der Monopolbildung im Internet vor (Erklärung dazu und zu weiteren Vorteilen: http://partner.opencritics.de/sp-dsp-user_idea). Zunächst haben wir mit Filmkritiken angefangen, Bücher werden bald folgen. Die Kritiken werden auf den Seiten angezeigt, die unsere Widgets nutzen (einige wenige Blogs), ausserdem auf unserer Portalseite und in einer Facebook-App. Wir sind eine kleine Internetagentur, die OpenCritics.de pro bono betreibt. Toll fände ich es, wenn wir uns irgendwann auch in Richtung Verein/Stiftung bewegen könnten. Derzeit sind wir ein kleines Team (hauptsächlich in unserem Büro in Hamburg) mit unterschiedlichstem Background (bei mir ein Juristischer, dann Webdesign-Background, zwei sind noch Studenten ...) Wenn jemand die Idee gefällt freuen wir uns über jeden Blogeintrag dazu, über jeden Tipp - und über jede Filmkritik :). Nun zurück zum Grund meiner Mail: Wenn also OpenStreetMap (oder jemand mit den OpentreetMap-Daten) jemals an Features arbeiten sollte, mit denen man lokale points-of-interest (Restaurant, Blumenladen, Aussichtspunkt, ...) subjektiv bewerten kann, so würde es mich freuen, wenn man hier vielleicht über eine Zusammenarbeit nachdenken könnte. Wobei Zusammenarbeit auch einfach bedeuten kann, dass wir unsere Technik/unsere Erfahrungen zum Thema Management von Nutzerkritiken einbringen. Würde mich freuen, wenn Ihr ggf an uns denkt. Und ja, ich weiss, das gibt es schon (Qype Co) - der Gag hier wäre aber, dass es sich um ein gänzlich freies System handeln würde (also sowohl Kartendaten als auch Kommentare/Bewertungen frei lizenziert). Was meint Ihr? Beste Grüße, Georg Georg v. Zimmermann LL.B. e.velope GmbH Max-Brauer Allee 218 22769 Hamburg T: +49 40 334 204 59 F: +49 40 334 204 60 M: +49 178 185 3211 g.v.zimmerm...@evelope.de http://www.evelope.de Geschäftsführer: Georg von Zimmermann, Joachim von Zimmermann, Amtsgericht Hamburg, HRB 111400 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarenders eingebaute pattern anpassen
In der osmarender.xml für Zoomstufe 17 sind Relationen vorgesehen, allerdings muß man am Anfang der Datei showRelationRoute=yes setzen, und der Relationsblock !-- Relation/Routes SDW -- am Ende der Regeln ist auskommentiert. Wenn man das umgeht, kann man zumindest die Wegstücke anders einfärben. Symbole oder refs an den Weg zu pappen tuts allerdings nicht, dafür müsste in der xsl entsprechendes vorgesehen sein. Das hatte ich auch gesehen. Theoretisch müsste es dann auch laufen wenn man showRelationRoute=yes und entsprechende Regeln auf andere Styles umkopiert. Tuts aber nicht. Jedenfalls nicht direkt übers XSL über XML Starlet. Ebenso wie Inner von Multipolygonen nur ausgeschnitten aber nicht nach rule ausgefüllt werden. Rendert mal über tilesAT local also orp, wird relation gleich ignoriert. Das scheint generell nicht zu laufen. In der XSL (6.0 Alpha 6 ) sind da einige Zeilen ab 1168, 1292 die sich um Relationen drehen, auskommentiert ist nichts. Ich verstehe aber zu wenig von der Materie um den Fehler zu finden. Hast du das denn in irgendeiner Version tatsächlich zum laufen gebracht, oder auch nur vermutet? Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
moin On 07.02.2010, at 12:06, Harald Schwarz wrote: Hallo zusammen, danke für eure Hinweise. Ich werde nochmal darüber nachdenken. Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wenn unter Adresse nur Informationen verstanden werden, mit denen ein Objekt lokalisiert bzw. per Brief angeschrieben, also adressiert werden kann, dann passen natürlich obige Kontaktinformationen nicht ins addr:* Schema. Es hängt also ganz davon ab, welchen Blick man auf eine Adresse wirft um zu entscheiden was ins Schema gehört und wie man es tagt. also der logik halber müsstest du dann auch addr:name vorschlagen. den wenn du nen gebäude mit mehreren mietern hast wird dir der rest der adresse nicht wirklich weiter helfen ;-) cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues von der Reit- und Wanderkarte
Am 7. Februar 2010 19:14 schrieb Alberto Nogaro bartosom...@yahoo.it: Manchmal ist nun die Karte im Hochgebirge zu dunkel, z.B.: http://topo.geofabrik.de/?lon=9.2495lat=45.8508zoom=15 ja, die ist m.E. generell zu dunkel. Insgesamt einfach 20-40% dessen, wie es jetzt ist, und das wäre noch schöner :D Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit Kartenupload auf Garmin eTrex HCx
Am 07/06/08 00:03, schrieb Florian Arnold: Hallo, Christoph Eckert schrieb am 05.07.2008 22:15: Ja. Meistens habe ich im Ordner Garmin zuerst die (funktionierende) alte gmapsupp.img gelöscht und dann die neue reinkopiert. hat bei mir immer perfekt funktioniert. Nehmen wir mal an alles ist OK: Ist im Garmin die Karte vielleicht abgeschaltet? Nein, es wird im Karten-Optionsdialog auch keine aktivierbare Karte in der Liste angezeigt. Das Problem hab ich auch gerade. Ich sehe schon, das Problem ist von der härteren (unbekannten) Sorte - oder ich habe einen Fehler gemacht, der so dämlich ist, dass wir alle nicht draufkommen ;-( Rücksetzen der Einstellungen mit Enter+Page+On hat nix geholfen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit Kartenupload auf Garmin eTrex HCx
Am 07/07/08 00:28, schrieb Florian Arnold: - Warum tritt das Problem nur bei mir auf? Ich werde ja wohl sicher nicht der einzige eTrex-Legend-HCx-Nutzer hier sein. Bei mir ist es (bzw. tut noch) auf einem extrex _vista HCx aufgetreten. Gruß Jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 7. Februar 2010 18:25 schrieb Mirko Küster webmas...@ts-eastrail.de: Soll das dann auch wieder mit Relationen gemacht werden, oder was sind diese sets? Eben keine Relationen die wieder als eigenes Objekt dutzende andere Objekte mit Rollen zusammen kitten. Genau das solls nicht sein. Objekte wie jetzt auch, nur vom editor unterstützt die Möglichkeit ein eigenes Set oder Schachtel ins Objekt bringen. m.E. rufst Du im Endeffekt nach einem einfachen Typ von Relation (der einfach ist, da er eingeschränkte Möglichkeiten hat, und z.B. nur eine feste Art von Rolle, um die man sich nicht kümmern braucht, weil der Editor das macht, könnte man z.B. Gruppe nennen) mit bedienerfreundlicher Editorunterstützung. Nichts dagegen, im Gegenteil, nur solange man das nicht programmiert bleibt es halt Wunschdenken. Diese Gruppen könnten z.B. den Effekt haben, dass alle Mitglieder bei Selektion markiert sind (oder eine Selektionsbox drumrum haben oder so), man könnte Gruppen gruppieren (also verschachteln), Gruppen zum Bearbeiten öffnen und wieder schließen, ohne dass man sie gleich ungruppieren muss, etc. Erstens schreibe ich dir zum 1000 male das ich das weiß und zweitens interessiert das jetzt garnicht. Der Normale Mapper ist froh wenn er ein Gebäudepolygon zusammen hat. In Grundstücken braucht man in der Breite noch nicht zu denken. Das machst du, ich machs auch, vielleicht noch zehn oder zwanzig andere. Die Masse packt es mangeles besserer Daten ans Haus oder einen Node. wenn man sich hier schon grundlegende Gedanken macht, kann man ruhig auch gleich sinnvolle Hierarchien vorschlagen, also z.B. Grundstück Gebäude Einheit (Laden, Wohnung, Büroeinheit) ggf. Untereinheit (Raum, Zimmer, Saal) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM SVN-Script
Am 7. Februar 2010 23:24 schrieb Max Andre telegnom@googlemail.com: Hallo, da ich keine Lust mehr hatte mir die neueste JOSM Version händisch auszuchecken und zu kompilieren habe ich mir ein Script für diesen Zweck gebaut. Das Script prüft erst ob die SVN-Version neuer ist als die Lokale. Wenn nicht wird die lokale Version gestartet. Wenn ja wird die aktuelle Version ausgecheckt und kompiliert. Falls das Repository nicht erreichbar ist versucht das Script die lokale Version zu starten. Sollte keine lokale Version vorhanden sein, beendet sich das Script. Wer Interesse daran hat kann es bei github [1] finden. Ich bin für jegliche Kritik und Anregungen offen... also immer her damit ;) Ohne Dir den Wind aus den Segeln nehmen zu wollen: das gibt's schon ;-). Ich hatte es auf meinem Rechner drauf, finde aber gerade den Autor nicht, da mein Netzteil kaputt ist (wo das installiert ist, s...@#!ss ital. Stromnetz). Habs doch: http://wiki.openstreetmap.org/wiki/User:Cobra/DE:JOSM-script Vielleicht interessiert Dich das ja, um mal zu vergleichen wie er's gemacht hat. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
m.E. rufst Du im Endeffekt nach einem einfachen Typ von Relation (der einfach ist, da er eingeschränkte Möglichkeiten hat, und z.B. nur eine feste Art von Rolle, um die man sich nicht kümmern braucht, weil der Editor das macht, könnte man z.B. Gruppe nennen) mit bedienerfreundlicher Editorunterstützung. Nichts dagegen, im Gegenteil, nur solange man das nicht programmiert bleibt es halt Wunschdenken. Meine Überlegung hat so garnichts mit einer Relation zu schaffen. Das wäre eigentlich nur eine Erweiterung der Objekte die wir haben. Völlig unabhängig von Relationen. Die sollen ja vorhande Objekte ansich fassen. Ich will die Möglichkeiten des Objektes selbst etwas erweitern. Wir haben jetzt z.B. ein Gebäude mit seinen üblichen Eigenschaften: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / /way Dieses Konstrukt ist natürlich begrenzt. Du kannst ihm nicht zweimal amenity, phone whatever verpassen. Ein Tag geht nur einmal, ein zweiter Wert würde den alten einfach überschreiben. Zu der Zeit wo man noch andere Sorgen und wenige Details hatte hats gereicht. Deswegen sind wir gezwungen alles einzeln abzulegen, gewisse Redundanzen zu schaffen, Krücken wie die Semikolongeschichte zu bauen und das dann ggf. wieder über ein neues Objekt, eben die Relation, wieder zu vereinen. Damit fahren wir aber eigentlich mit Kirche, Marktplatz und Rathaus ums Dorf. Nun meine Überlegung. Warum erweitern wir nicht einfach das Objekt selbst und ermöglichen so mit zusätzlichen Sets, Groups, Name Wumpe, die Eigenschaften gleich direkt am Objekt zu belassen, vermeiden Redundanzen und erschlagen Krücken durch Tagüberschneidungen? Das könnte jetzt mal vereinfacht so aussehen: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / object group id='123456.001' / tag k='amenity' v='bank' / object group id='123456.001' / object group id='123456.002' / tag k='amenity' v='bank' / object group id='123456.002' / /way Ich weiß nun nicht wie schwierig das ist um es in einer zukünftigen API vorzusehen. Ansich wäre es ja nur eine neue Tagrule und eine Erweiterung der ID, um die Gruppen Sub ID anhängen zu können. Ich denke mal die IDs sind begrenzt, wo es haken wird. Das schwierigste wird die Umsetzung im Editor sein. Aber wenn ich den Relationseditor sehe, scheint es da fähige Leute zu geben die das können. Dann ist natürlich auch die Frage wie Renderer das dann auswerten. Nur schlimmer kann es für die im Grunde auch nicht kommen. Die haben meist unzusammenhängende POI Wolken liegen und müssen herumrechnen, verdrängen etc. Vielleicht würde eine saubere Gruppierung sogar eine besser Grundlage schaffen. wenn man sich hier schon grundlegende Gedanken macht, kann man ruhig auch gleich sinnvolle Hierarchien vorschlagen, also z.B. Grundstück Gebäude Einheit (Laden, Wohnung, Büroeinheit) ggf. Untereinheit (Raum, Zimmer, Saal) Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 8. Februar 2010 02:53 schrieb Mirko Küster webmas...@ts-eastrail.de: Meine Überlegung hat so garnichts mit einer Relation zu schaffen. Das wäre eigentlich nur eine Erweiterung der Objekte die wir haben. Völlig unabhängig von Relationen. Die sollen ja vorhande Objekte ansich fassen. Ich will die Möglichkeiten des Objektes selbst etwas erweitern. ich denke, wir schreiben da etwas aneinander vorbei, IMHO beschreibst Du einen Typ Relation, indem Du dem Way die Fähigkeiten von Relationen geben willst (Du nennst die Relation Way, aber im Prinzip ist es eine Relation, die zusätzlich zu den Nodes auch noch Ways enthält. Wenn Du die Nodes und die Richtung weglassen würdest, wäre es nicht so kompliziert ;-) Dieses Konstrukt ist natürlich begrenzt. Du kannst ihm nicht zweimal amenity, phone whatever verpassen. ... Krücken wie die Semikolongeschichte zu bauen die Lösung hast Du ja selbst schon geschrieben: mit dem Semikolon als Trenner kann man mehrere Werte an einen Schlüssel hängen. Die Nachteile sind, dass man a) bei den übrigen Tags z.T. nicht klar ist, für welchen Wert sie gelten sollen (oder für alle?) b) die derzeitigen Anwendungen nicht damit klar kommen Dann ist natürlich auch die Frage wie Renderer das dann auswerten. um Renderer geht es hier m.E. nur nachgeordnet Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. Sobald Du von Adressen und Hausnummern sprichst, geht es im Prinzip um Grundstücke. Solange man die nicht hat oder grob rekonstruieren kann (geht oft über Zäune, Mauern und andere Grenzen, auch wenn das nicht zwangsläufig parzellenscharf ist), kann man die Information auch als Punkt anbringen, oder eben an andere POI oder Gebäudeumrisse dort hängen. Das kann m.E. aber nur ein Zwischenschritt sein, als Ziel sehe ich schon die Grundstücke - die sind in unserer Weltordnung nunmal die Einheit in diesem Bereich: Häuser kommen und gehen, Grundstücke sind erstaunlich konstant (klar, es gibt auch Gegenbeispiele wie z.B. Flurbereinigung, das sind aber langsame, seltene (derzeit) und transparente (idealerweise) Prozesse, die öffentlich ablaufen). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
ich denke, wir schreiben da etwas aneinander vorbei, IMHO beschreibst Du einen Typ Relation, indem Du dem Way die Fähigkeiten von Relationen geben willst (Du nennst die Relation Way, aber im Prinzip ist es eine Relation, die zusätzlich zu den Nodes auch noch Ways enthält. Wenn Du die Nodes und die Richtung weglassen würdest, wäre es nicht so kompliziert ;-) Ja, im übergeordneten Sinn ist es eine Relation aber diese Erweiterung des eigentlichen Objektes hat nichts mit der in OSM gebräuchlichen Form einer Relation zu tun. Der Way wird nur um eine Schachtel erweitert, statt dafür wieder eine eigene extra Relation zu benutzen. Ich würde das Kind dann auch gerne von dieser Bezeichnung fernhalten, das alleine lässt manchen schon wegrennen. Teilweise zu Recht. die Lösung hast Du ja selbst schon geschrieben: mit dem Semikolon als Trenner kann man mehrere Werte an einen Schlüssel hängen. Die Nachteile sind, dass man a) bei den übrigen Tags z.T. nicht klar ist, für welchen Wert sie gelten sollen (oder für alle?) b) die derzeitigen Anwendungen nicht damit klar kommen Eben deswegen ist das Semikolon eine Krücke und keine Lösung, sollte es auch nicht werden. Bei mehreren Werten muss der Anwender peinlich darauf achten das Werte in der richtigen Reihenfolge zueinander stehen. Aus der Praxis wissen wir wie anfällig sowas ist. Semikolon ist eine Sackgasse und halbgare Notlösung. Das müsste man mal richtig an den Eiern packen. Sobald Du von Adressen und Hausnummern sprichst, geht es im Prinzip um Grundstücke. Zum x ten male. Es geht mir nicht um Grundstücke und deren Nummern. Grundstücke und deren Grenzen sind Luxusdetails die nur wenige bringen können. Wer solche Daten erbringt der weiß auch wie, die Masse interessierts erstmal nicht. Die ist froh eine Gebäudekoordinate oder sogar eine Form zu haben. Da klemmts erstmal primär. Grundstücke werden für die Masse erst interesannt, wenn es auch entsprechende Grundlagen gibt. Beispielsweise flächendeckende Luftbilder. Abseits der Ballungsgebiete wirds da auch zukünftig zappenduster aussehen. AeroWest nützt mir z.B. garnichts. Alte Goggle Bilder bedingt, da hats hier seit jeher nur für die 10 Jahre alten gereicht. Bleiben nur die LVA, aber da wird man noch lange nichts reißen. Oberpfalz war Glück. Bayern kann es sich leisten, andere müssen Geld verdienen. Es ging hier um Kontaktdetails und eben Probleme wie Tagüberschneidungen. Ja, Adressen = Grundstück, haben wir bis zum erbrechen durchgekaut. 99% können aber Grundstück nicht und haben nur Gebäude (Koordinate). Erstmal muss man das Gebäude und anderes lösen. Und das mit einer Methode, bei der auch Joe the Mapper problemlos loslegen kann. Auch wenn das manche hier immer wieder gerne ausblenden. Die Masse sind hier keine Informatiker oder Profis. Über weitergehendes wie aus Daten ne Karte machen reden wir gleich garnicht. Da verzweifle ich aktuell alle 5 Minuten dran. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM SVN-Script
Am 08.02.2010 02:17, schrieb Martin Koppenhoefer: Am 7. Februar 2010 23:24 schrieb Max Andretelegnom@googlemail.com: Hallo, da ich keine Lust mehr hatte mir die neueste JOSM Version händisch auszuchecken und zu kompilieren habe ich mir ein Script für diesen Zweck gebaut. Das Script prüft erst ob die SVN-Version neuer ist als die Lokale. Wenn nicht wird die lokale Version gestartet. Wenn ja wird die aktuelle Version ausgecheckt und kompiliert. Falls das Repository nicht erreichbar ist versucht das Script die lokale Version zu starten. Sollte keine lokale Version vorhanden sein, beendet sich das Script. Wer Interesse daran hat kann es bei github [1] finden. Ich bin für jegliche Kritik und Anregungen offen... also immer her damit ;) Ohne Dir den Wind aus den Segeln nehmen zu wollen: das gibt's schon ;-). Ich hatte es auf meinem Rechner drauf, finde aber gerade den Autor nicht, da mein Netzteil kaputt ist (wo das installiert ist, s...@#!ss ital. Stromnetz). Habs doch: http://wiki.openstreetmap.org/wiki/User:Cobra/DE:JOSM-script Hallo, nein Cobras Script läd die aktuelle Version vom Server runter und führt sie aus. Mein Script lädt die Source aus dem SVN und kompiliert sie. Da ist ein gewaltiger Unterschied! Cobras Script benutze ich selber auch, wenn ich die offizielle latetst haben will. Die wird aber nur einmal am Tag aktualisiert. An guten Tagen gibt's aber zahlreiche Änderungen im SVN. Um immer ganz aktuell zu sein muss man sich halt die Arbeit machen und die Sourcen selbst kompilieren. Grüße Max ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am Montag 08 Februar 2010 02:53:45 schrieb Mirko Küster: Nun meine Überlegung. Warum erweitern wir nicht einfach das Objekt selbst und ermöglichen so mit zusätzlichen Sets, Groups, Name Wumpe, die Eigenschaften gleich direkt am Objekt zu belassen, vermeiden Redundanzen und erschlagen Krücken durch Tagüberschneidungen? +1 Das könnte jetzt mal vereinfacht so aussehen: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / object group id='123456.001' / tag k='amenity' v='bank' / object group id='123456.001' / object group id='123456.002' / tag k='amenity' v='bank' / object group id='123456.002' / /way ich nehme mal an, das 123456 in den groups bezieht sich auf die way id. dann kannst du die genauso gut weglassen, denn die ist durch den way ja bereits gegeben (zumindest in der xml-darstellung; wie das die datenbank speichert - keine ahnung). aber die idee, tags innerhalb eines objekts - sei es jetzt node oder way - zu gruppieren, ist etwas, das ich schon lange vermisse. bisher versucht man sowas mehr schlecht als recht in das key/value-schema zu pressen. manche versuchen das auch mit semikolons. als reine auflistung, was fuer viele faelle ausreichend ist, finde ich das durchaus sinnvoll, aber sobald man eben verschiedene attribute gruppieren oder sortieren will, braucht's was anderes. andererseits, wenn ich's mir recht ueberlege, ist das sehr aehnlich zu relationen, aber doch etwas anders... ich bin dafuer, neben node,way und relation den typ group einzufuehren, der nichts anderes macht, als zusammengehoerende attribute eines objekts zu gruppieren. das wuerde nebenbei auch einige probleme mit vielen pseudo-keys erschlagen, die man dann gar nicht mehr braucht... Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. grundstuecke sind eben keine andere geschichte! ob jetzt gebaeude, grundstueck, briefkasten oder schiessmichtot, es sind alles objekte mit eigenschaften. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap // OpenCritics
Am Montag 08 Februar 2010 02:31:59 schrieb Martin Koppenhoefer: Am 7. Februar 2010 23:40 schrieb g.v.zimmerm...@evelope.de Nun zurück zum Grund meiner Mail: Wenn also OpenStreetMap (oder jemand mit den OpentreetMap-Daten) jemals an Features arbeiten sollte, mit denen man lokale points-of-interest (Restaurant, Blumenladen, Aussichtspunkt, ...) subjektiv bewerten kann, so würde es mich freuen, wenn man hier vielleicht über eine Zusammenarbeit nachdenken könnte. Wobei Zusammenarbeit auch einfach bedeuten kann, dass wir unsere Technik/unsere Erfahrungen zum Thema Management von Nutzerkritiken einbringen ich finde die idee auch nicht schlecht, fragt sich nur, ob man damit gegen die bestehenden systeme ankommen kann; so ein system lebt ja schliesslich von seinen usern; und aus usersicht sehe ich im moment nicht den mehrwert... Diese Art von Daten (Kritiken) sind in OSM nicht erwünscht, so dass sich die Anbindung einer weiteren Datenbank dafür wie Ihr sie aufbaut anbietet. richtig. aber eine einfache verknuepfung ueber die IDs sollte die verbindung herstellen koennen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lowrance Endura
Von Lowrance gibt es das Hand-GPS Endura in drei Versionen. Wer kennt/hat so ein Gerät und kann berichten? Habe dafür mal eine Wikiseite aufgemacht: http://wiki.openstreetmap.org/wiki/DE:Lowrance_Endura Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
