Re: [Talk-de] Potlach! *kotz*
Frederik Ramm [EMAIL PROTECTED] wrote: Davon, jetzt erstmal auf die Bremse zu treten und sich vernuenftige Software zu ueberlegen, halte ich wenig. Bis wir uns auf vernuenftige Software geeinigt haben, ist das Projekt tot ;-) Das sehe ich auch so. Wenn gescheite Software [tm] da ist kann man die Daten immer noch in deren Format konvertieren... Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Hallo, Das kann man doch ueberhaupt nicht vergleichen. OSM ist ein Crowdsourcing-Projekt. Da kommt es nicht auf einzelne Entwickler an, sondern auf die Masse von Mitmachern, von denen jeder nur ein kleines bisschen zum Erfolg beitraegt. So wie eben die Wikipedia auch; da gibt es zwar einen harten Kern von Aktiven, aber ohne die Massen von Leuten, die da mitmachen, koennten die nichts erreichen. Wenn schon der Vergleich mit KDE hinken soll, hinkt der Vergleich mit Wikipedia noch viel mehr. Wikipedia ist eine Ansammlung von Texten und Bildern, die schwach miteinander verknüpft sind. Eine Straßenkarte ist ein straffes mathematisch abgesichertes Gebilde. Kommt eben drauf an, was man will. Ein GIS, das die Daten nur schwach verknüpft kann man so aufziehen, aber solange eine digitale Karte eine ziemlich zentrale Rolle hat, gibts sehr strenge Regeln. Der kürzeste Weg von X nach Y ist eine exakte Lösung einer exakten Problemstellung und wenn OSM was anderes ausgibt, arbeiet OSM fehlerhaft. Wenn die Daten erstmal da sind, dann kommen die Anwendungsprogram- mierer ganz von allein. Nö, das sollte Hand in Hand gehen. Erst ein schoenes Korsett aufbauen und das dann von willigen Arbeitsbienen nach Vorschrift befuellen lassen, das geht halt (hier) nicht. Warum diese Panik vor einem angeblichen Korsett um das es hier gar nicht geht? Es geht nach wie vor darum, das Erarbeitete zu dokumentieren und zu schützen und nicht darum ein Korsett in den leeren Raum zu stellen. Die Programmierer, die wir brauchen, tun sich nicht durch perfekte Algorithmen und coole Optimierungen hervor, sondern dadurch, dass sie mit Crowdsourcing angemessen umgehen koennen. Hier sind keine Elfenbeinturmbastler gefragt, die nur mit idealen Bedingungen und punktfoermigen Massen rechnen koennen. Siehe oben: es gibt falsch und richtig. Wenn mich das Navi auffordert, gegen die Fahrtrichtung in die Einbahnstraße abzubiegen, hat das Navi (im KFZ-Modus) einen Fehler gemacht, da gibts nichts dran zu deuteln. Egal, ob Crowdsourcingprogger oder Elfenbeinspezialist - diese Randbedingung steht. Erwarte ich deshalb, dass alle OSM-Daten von Anfang an perfekt sind und tolles Routing ermöglichen? Natürlich nicht. Aber was ich schon gerne sehen würde, ist ein Weg dorthin und genau der fehlt mir. Derzeit wird alles immer noch chaotischer und undurchsichtiger und alles was in Richtung Qualitätssicherung und Anwender-API geht, wird abgewürgt. Wer fuer OSM gute Software machen will, der muss mit unvollstaendigen, falschen, schmutzigen, unvorhergesehen strukturierten Daten umgehen koennen. Das ist eine ganz andere Welt als bei der kommerziellen Konkurrenz, wo von oben festgelegt wird, wie's gemacht wird, und dann faehrt der Video-Van los... Und genau das ist eine unmögliche Forderung. Da kannst du genauso von den Leuten erwarten, dass sie C-Programme schreiben, die mit einem Pointer, der irgendwo hinzeigt, bitte etwas sinnvolles machen sollen. Ein falscher Wert, der einen falschen Graphen erzeugt, erzeugt ein falsches Ergebnis - so einfach ist das. Und die Attributsebene? Ich kann schon ein Programm schreiben das 100erte von ähnlichen Beschreibungen eines Werts filtert und irgendwie interpretiert. Dann habe ich aber mit viel Aufwand etwas erreicht, das immer noch viel ungenauer ist als ein popliger Zahlenwert, der mit einer genauen Definition verbunden ist. Damit soll man Anwendungsentwickler anlocken? Schau Dir doch mal das MediaWiki an und was das (software-design- maessig) fuer ein Haufen Schrott ist. Hat die Wikipedia aber bis jetzt nicht zu Fall gebracht. Davon, jetzt erstmal auf die Bremse zu treten und sich vernuenftige Software zu ueberlegen, halte ich wenig. Bis wir uns auf vernuenftige Software geeinigt haben, ist das Projekt tot ;-) Wer will denn auf die Bremse treten, davon war nie die Rede. Man sollte sich nur vielleicht überlegen ob es Beschleunigung um jeden Preis sein muss. Derzeit ist dieser Preis, dass die vorhandene Datenbasis verunstaltet wird. Da das Projekt mich als Elfenbeinturmentwickler nach deiner Aussage nicht brauchen kann, mach ich inzwischen mit den nativen AND-Daten weiter und hab mir einen schnellen Einlesefilter dafür geschrieben. Deren Shapeformat ist wirklich alles andere als schön, hat aber einen Vorteil - es ist sauber dokumentiert und kann alles, was man fürs Routing braucht. Ich mag lieber coole schnelle Algorithmen machen, statt ein 'wie taggen wir denn heute'- Schätzeisen. In diesem Sinne - Danke ans OSM-Projekt für die AND-Daten und als Tagger stehe ich weiterhin zur Verfügung. Grüsse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Friedhelm Schmidt wrote: Also, ich bin überhaupt nicht begeistert. Die importierten Daten sind weder vollständig noch korrekt. In meiner Gegend rund um Heilbronn sind kaum Orte hinzugekommen, aber mindestens 30% der bestehenden wurden dupliziert. Hallo Friedhelm, kannst du bitte mal in der opengeodb selbst nachprüfen, wie unvollständig die Daten sind? http://fa-technik.adfc.de/code/opengeodb.pl?locid=584;c=DE;distance=15 bringt schon mehr als hundert Treffer. Kann es sein, dass der Landkreis Heilbronn tatsächlich mehr als 1000 km^2 umfasst? Bei den Duplizierten sieht man schön, dass zum Teil die Koordinaten recht kreativ sind. Oder liegt Löwenstein neuerdings im Tal? Ist 49.09940 / 9.38139 so weit daneben? Typischerweise sind die Abweichungen eher größer, weil die Rohdaten nur mit einer Genauigkeit auf Zehntelminuten vorlagen. Wie ich lese, geht es vielen anderen Mappern ähnlich. Vielleicht sollte man in Zukunft einen lokal begrenzten Probelauf machen und anhand des Resultats 'rumfragen ob ein Import sinnvoll und gewünscht ist. Für mich kam die Aktion auch etwas überraschend - ein Probelauf in einem kleineren Gebiet wäre kein Fehler gewesen. Im Moment weiss ich nicht, wann Sven hier mit dem letzten, erheblich besserten Dump ein update vornehmen wird. Er hatte hier zwar um aktuellere Daten gebeten. Die Lizenzproblematik von OSM hatte das aber leider blockiert. Demzufolge wich er auf alte, fehlerhafte Daten aus. Mit dem aktuellen Dump dürften ein paar neue Fehler hinzukommen, insgesamt aber auch die von dir gewünschte Anzahl an Orten bei Heilbronn hinzugewinnen. Meine Empfehlung für ein Update: - Abgleich passender Namen nicht über die lange Schreibweise von opengeodb, sondern über die kurze Schreibweise, die als sortname (ASCII) in der opengeodb vorliegt - Beschränkung auf die Ebenen 6 (Gemeinden), 7 (Orte), 8 (Ortsteile) Löwenstein würde dabei dennoch doppelt erscheinen, einerseits als Gemeinde, andererseits als eine der Ortschaften/Ortsteile: http://fa-technik.adfc.de/code/opengeodb.pl?parts=20354;c=DE 82642 Gerberhäusle 49.1000 / 9.3833 82643 Hirrweiler49.0931 / 9.4089 82644 Hößlinsülz49.1167 / 9.3667 82645 Lichtenstern 49.1000 / 9.4000 81304 Löwenstein49.0994 / 9.3814 81305 Reisach 49.1078 / 9.3981 82646 Rittelhof 49.1019 / 9.3706 82647 Teusserbad49.0833 / 9.3833 Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Schweizer Grenzen
Halli Hallo, Das Schweizerische Bundesamt für Statistik (nicht swisstopo) hat frei verfügbare ShapeFiles der Schweizer Gemeinde-, Bezirks-, Kantons- und Staatsgrenzen. http://www.bfs.admin.ch/bfs/portal/de/index/dienstleistungen/geostat/datenbeschreibung/generalisierte_gemeindegrenzen.html Unkommerzielle Verwendung unter Angabe der Quelle ist erlaubt. Komerzielle Nutzer müssen nachfragen. Hat jemand Lust abzuklären wie sich das mit einer cc-by-sa-2.0 Lizenz verträgt? Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Automaten Tag
Jens schrieb: Machst du? Ich kenne das noch nicht. Jens Hmm, mir fehlen irgendwie die Englischkenntnisse dazu. Im Prinzip muss man halt auf http://wiki.openstreetmap.org/index.php/Proposed_features nen entsprechenden Eintrag dazu anlegen. Mehr steht auf der Seite. MfG ah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Martin Trautmann schrieb: - Beschränkung auf die Ebenen 6 (Gemeinden), 7 (Orte), 8 (Ortsteile) Löwenstein würde dabei dennoch doppelt erscheinen, einerseits als Gemeinde, andererseits als eine der Ortschaften/Ortsteile: Bei dem denkst du momentan noch irgendwie falsch, Martin. Alles was sich nicht als Punkt in OSM darstellen lässt, sollte nur als Relation importiert werden. Um ein Beispiel bei mir in der Gegend zu bringen: Die Gemeinde Mönchsdeggingen besteht aus folgenden Orten: Mönchsdeggingen, Untermagerbein, Merzingen, Rohrbach, Schaffhausen, Ziswingen. Momentan ist der Ort Mönchsdeggingen in OSM als Node mit ogdb:type=Gemeinde vorhanden, die anderen Orte verweisen mit ihrem is_in Tag auf diesen Node. Richtig wäre eigendlich eine Relation Mönchsdeggingen anzulegen, zu auf die dann die einzelnen Orte verweisen. Das selbe gilt für Kreisfreie Städte und die ganzen anderen Fälle in denen es momentan noch zwei Nodes mit unterschiedlichen ogdb:type Tags gibt. MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Relation Editor in JOSM
Hi, wie weit kann man JOSM eigendlich momentan Relations bearbeiten? Ist das soweit schon alles fertig? inbesondere @ Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relation Editor in JOSM
wie weit kann man JOSM eigendlich momentan Relations bearbeiten? Ist das soweit schon alles fertig? inbesondere @ Frederik Das geht schon seit ner ganzen Weile recht gut. Diverse Wälder mit Löchern und Seen mit Inseln zeugen davon :) Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Wälder besser abzeichnen mit IR-Bilder n
Hallo, ich weiß nicht, ob das schon jemand entdeckt hat, aber über das Landsat-WMS (z.B. per JOSM-Plugin) kann man auch Bilder aus dem Infrarot-Spektrum beziehen. Der Vorteil: Wälder sind schön dunkel eingefärbt, heben sich von umliegenden Wiesen und Äckern sehr gut ab und lassen sich somit wesentlich besser abpinseln. Einrichtung: Im Konfigurationspanel des WMS-Plugins in JOSM einen neuen Eintrag z.B. namens Landsat IR anlegen und folgende URL eintragen: http://onearth.jpl.nasa.gov/wms.cgi?request=GetMaplayers=global_mosaic_basestyles=IR3srs=EPSG:4326format=image/jpeg Ein Neustart des Programms ist nicht erforderlich. Gruß, Wabba ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wälder besser abzeichnen mit IR-Bilder n
Daniel Schmidt schrieb: Hallo, ich weiß nicht, ob das schon jemand entdeckt hat, aber über das Landsat-WMS (z.B. per JOSM-Plugin) kann man auch Bilder aus dem Infrarot-Spektrum beziehen. Gruß, Wabba Mhh... ich habe zwar von dem Layer gewusst, aber auf die Idee, ihn in JOSM zu laden, bin ich noch nicht gekommen, danke für den grandiosen Tipp. Der IR-Layer ist auch recht gut dafür, kleine Flüsse und Bäche zu finden, wenn man grob weiß, wie sie laufen aber man sie auf dem normalen Landsat-Bild nicht sieht. Jannis smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Andreas Hubel wrote: Martin Trautmann schrieb: - Beschränkung auf die Ebenen 6 (Gemeinden), 7 (Orte), 8 (Ortsteile) Löwenstein würde dabei dennoch doppelt erscheinen, einerseits als Gemeinde, andererseits als eine der Ortschaften/Ortsteile: Bei dem denkst du momentan noch irgendwie falsch, Martin. Alles was sich nicht als Punkt in OSM darstellen lässt, sollte nur als Relation importiert werden. Hallo Andreas, wie die Daten zu importieren sind, das kann ich nicht beurteilen und beeinflussen - ich beschreibe nur, wie die Daten in der opengeodb organisiert sind. Dort wird mit genau solchen Relationen gearbeitet, wie du sie wünschst. Um ein Beispiel bei mir in der Gegend zu bringen: Die Gemeinde Mönchsdeggingen besteht aus folgenden Orten: Mönchsdeggingen, Untermagerbein, Merzingen, Rohrbach, Schaffhausen, Ziswingen. Momentan ist der Ort Mönchsdeggingen in OSM als Node mit ogdb:type=Gemeinde vorhanden, die anderen Orte verweisen mit ihrem is_in Tag auf diesen Node. Richtig wäre eigendlich eine Relation Mönchsdeggingen anzulegen, zu auf die dann die einzelnen Orte verweisen. Wenn der Punkt von Mönchsdeggingen den Ort bezeichnet, dann sollte der wohl am ehestem als Ort oder Ortschaft markiert werden. Er und alle anderen Orte der Gemeinde sollten dann verweisen auf die Gemeinde Mönchsdeggingen. Es ist grundsätzlich problematisch, eine Fläche nur durch einen Punkt zu markieren. Der Mittelpunkt der Ortschaft Mönchsdeggingen liegt vermutlich an anderer Stelle als der Mittelpunkt der Gemeinde Mönchsdeggingen - und eine Möglichkeit, die Gemeindekoordinaten festzulegen, ist ein solcher Mittelpunkt (Umkreis, Schwerpunkt usw.) Eine andere Möglichkeit ist natürlich, die Koordinate auf die Gemeindeverwaltung zu legen - dann würden Punkte für Ort und Gemeinde direkt übereinander liegen. Für den Import besser wäre vielleicht, bei Duplikaten auf Orts- und Gemeindeebene die Gemeinde zu übergehen und nur den Ort mit opengeodb-Daten zu übernehmen. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wälder besser abzeichnen mit IR-Bilder n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Interessant währen auch Fehlfarben Komposite z.B. mit Landsat kanal 4,3,2 auf den RGB Kanälen damit könnte man verschiedene Bereiche auch sehr gut optisch trennen. oder auch NDVI Bilder. NDVI gitb es habe es aber gerade auf die schnelle nicht in JOSM bekommen. Grüße Fabian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (MingW32) Comment: GnuPT 2.9.1 iD8DBQFHljVf8pTXCZH6O18RApZfAKD+Xg2JybgXj+iULiGQ3XTP5zwxfwCg7xd2 1IQ3iguNCxVyYLsWts4v1NU= =mNFP -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Frederik Ramm schrieb: Wer fuer OSM gute Software machen will, der muss mit unvollstaendigen, falschen, schmutzigen, unvorhergesehen strukturierten Daten umgehen koennen. Das ist eine ganz andere Welt als bei der kommerziellen Konkurrenz, wo von oben festgelegt wird, wie's gemacht wird, und dann faehrt der Video-Van los.. Nichts desto trotz halte ich von freien Tags nicht viel, man sollte sich auf einen gemeinsamen Standart einigen und diesen auch verpflichtend einführen. Freie Software hin und her, aber nachdem die Daten ja nicht nur zum Scherze da sind, sondern später evtl. auch mal in Navis und was weiss ich verwendet werden sollen, müssen auch alle Wege gleich getaggt sein und nicht so, dass jeder Mapper einen eigenen Schlüssel einführt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Joerg Fischer schrieb: Ich würde mir das gerne mal mit der History Funktion von http://crschmidt.net/osm/osm.html?zoom=0lat=49.77483lon=10.02944layers=BT anschauen Hab ich mir gerade angesehen, ich (oder mein Firefox?) kann das nicht bedienen. Ich seh nur die Dinge, die ich direkt in openstreetmap.org auch sehe. Du musst den Link Download current view bennutzen, dann läd er sich die aktuellen Daten über die API runter und stellt die dar. In deinem letzen Fall http://crschmidt.net/osm/osm.html?lat=50.7451lon=12.9933zoom=10layers=B0FT sieht man z.B. das die Primary durch den Ort momentan fehlt. Die History erreicht man wenn man eine Straße anklickt und dann auf Edit und dort dann auf History klickt. Für einen Node der gelöschten Straße wäre das z.B.: http://crschmidt.net/osm/history.html?type=nodeid=27341389 Für Wege wäre das http://crschmidt.net/osm/history.html?type=wayid=22419114 Falls du also die Id des weges noch hast kannst du nachschauen, wer den gelöscht hat. Man musste das JS das die OSM Daten vom Server läd, entsprechend anpassen, das es auch die historischen anzeigt. MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Schweizer Grenzen
Sali zämme, OK, das sind trotzdem stark generaliserte Datensätze, immeherin besser als nicht. F. Ramm hatte schon einmal dem BFS geschrieben, im Zusammenhang mit dem Erstellen des Mini-planet für die Schweiz (clipping): Meinst Du die, die man fuer 90 Fr. als offene Datei kaufen kann, oder bieten die auch was kostenloses an? Ich koennte ja mal hinschreiben. Und die Antwort: Sie sagen das hier: Wenn ich Sie richtig verstehe, benutzen Sie unsere Landes- oder Kantonsgrenzen (Generalisierungsstufe 3) als Clipcover um die Strassendaten auszuschneiden. Im Endprodukt werden weder die Grenzen als Ganzes noch Teile davon weitergegeben. Wenn dieser Sachverhalt zutrifft wird dies nach unseren nicht so strengen Massstäben nicht als 'kommerzielle Nutzung' betrachtet und ist somit nicht Bewilligungspflichtig. Als einzige Freie Datensatz gibt das (OK, eher witzig): http://schaer.freeflux.net/blog/archive/2007/03/14/gemeindegrenzen- der-schweiz.html Viele Grüsse Marc Le 22 janv. 08 à 13:59, Raphael Studer a écrit : Halli Hallo, Das Schweizerische Bundesamt für Statistik (nicht swisstopo) hat frei verfügbare ShapeFiles der Schweizer Gemeinde-, Bezirks-, Kantons- und Staatsgrenzen. http://www.bfs.admin.ch/bfs/portal/de/index/dienstleistungen/ geostat/datenbeschreibung/generalisierte_gemeindegrenzen.html Unkommerzielle Verwendung unter Angabe der Quelle ist erlaubt. Komerzielle Nutzer müssen nachfragen. Hat jemand Lust abzuklären wie sich das mit einer cc-by-sa-2.0 Lizenz verträgt? Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wälder besser abzeichnen mit IR-Bildern
Moin, On Tue, 22 Jan 2008 15:57:57 +0100 Daniel Schmidt [EMAIL PROTECTED] wrote: Hallo, ich weiß nicht, ob das schon jemand entdeckt hat, aber über das Landsat-WMS (z.B. per JOSM-Plugin) kann man auch Bilder aus dem Infrarot-Spektrum beziehen. Der Vorteil: Wälder sind schön dunkel eingefärbt, heben sich von umliegenden Wiesen und Äckern sehr gut ab und lassen sich somit wesentlich besser abpinseln. hmmm, also in meiner Gegend erscheinen Flüsse irgendwie doppelt, das sieht so aus, als wenn man zweimal das gleiche Bild irgendwie verschoben aufeinanderlegt. also nicht wirklich brauchbar. MfG Andreas Kemnade ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
André Reichelt [EMAIL PROTECTED] writes: Frederik Ramm schrieb: muss mit unvollstaendigen, falschen, schmutzigen, unvorhergesehen strukturierten Daten umgehen koennen. Standart 'nuff said. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Betr.: Anonymes Editieren
mallok schrieb: Ui! Und gibt es irgendwo einen Hinweis darauf, in welchen Laendern GPS mapping verboten ist? mallok -Ursprüngliche Nachricht Es gibt Laender gibt, in denen GPS-Mappen unter Knast-Androhung verboten ist (China, China ist ein echtes Thema! Kenne das von Bekannten, welche in der Navi-Branche beschäftigt sind...:-( MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relation Editor in JOSM
Hallo, wie weit kann man JOSM eigendlich momentan Relations bearbeiten? Ist das soweit schon alles fertig? inbesondere @ Frederik JOSM hat einen generischen Relation-Editor, mit dem Du alles machen kannst, also beliebige Relations mit beliebigen Members und beliebigen Tags aufstellen. Allerings laesst der, besonders fuer Alltagsfaelle, etwas Komfort vermissen, und es gibt, wie im Rahmen des OpenGeoDB-Imports rauskam, einen Bug beim Hochladen von Relations, die Relations enthalten (hier ist nicht sichergestellt, dass die referenzierten Relations vor den referenzierenden hochgeladen werden). Ich plane/erhoffe mir fuer die Zukunft, dass wir kofortablere Editiermoeglichkeiten fuer haeufige Relations haben, eventuell sogar dahingehend, dass dem Durchschnittsuser gar nicht mehr angezeigt wird, dass er eine Relation bearbeitet, sondern ein Abbiegeverbot usw. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Schweizer Grenzen
OK, das sind trotzdem stark generaliserte Datensätze, immeherin besser als nicht. Sie sind jedenfalls besser als die Kantonsgrenzen die wir bis jetzt auf Out-of-Date Maps gefunden haben. F. Ramm hatte schon einmal dem BFS geschrieben, im Zusammenhang mit dem Erstellen des Mini-planet für die Schweiz (clipping): Meinst Du die, die man fuer 90 Fr. als offene Datei kaufen kann, oder bieten die auch was kostenloses an? Ich koennte ja mal hinschreiben. Sie sagen das hier: Wenn ich Sie richtig verstehe, benutzen Sie unsere Landes- oder Kantonsgrenzen (Generalisierungsstufe 3) als Clipcover um die Strassendaten auszuschneiden. Im Endprodukt werden weder die Grenzen als Ganzes noch Teile davon weitergegeben. Wenn dieser Sachverhalt zutrifft wird dies nach unseren nicht so strengen Massstäben nicht als 'kommerzielle Nutzung' betrachtet und ist somit nicht Bewilligungspflichtig. In diesem Fall würden wir die Daten ja nicht mehr nur zum clippen verwenden sondern wirklich als Grenzen ablegen. Natürlich ist es noch immer keine Kommerzielle nutzung und wäre vielleicht auch nicht Bewilligungspflichtig. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
