Re: [Talk-de] Potlach // Baukasteneditor // RFC: Einschraenkung durch Relationen?
On Saturday, 19 January 2008 18:52:22 +0100, Christian Koerner [EMAIL PROTECTED] writes: [...] Eine Idee die mir schon seit einiger Zeit im Kopf rumschwirrt, ist das Sperren von Wegen durch die Verwendung von Relationen. Wir haben sie nun mal, warum sollte man sie nicht sinnvoll nutzen?! Sieht man den Streckenverlauf einer Autobahn oder eines Autobahnabschnitts als 'sicher' an, da die Wege nicht von den (sagen wir mal 50) vorhandene GPS-Traces abweichen, legt man eine Relation fuer die Autobahn an. type=lock Die 'sicheren' Wege gibt man als Mitglied (Member) der Relation an, die Rolle/Funktion koennte 'node_position_lock', 'name_edit_lock', 'ref_edit_lock' und so weiter sein, um die Verschiebung von Nodes, das Bearbeiten des 'name'- bzw. des 'ref'-Tags zu verhindern. Wann definiert man einen Wegabschnitt als perfekt, aehm :-), komplett? Momentan fahre ich bspw. einige Strecken ab, nicht um die Wege einzupflegen, denn der ist bereits komplett, sondern um Dinge wie Bruecken, Tunnel und Dinge laengs des Weges (Tempolimits und sonstige Schilder) aufzunehmen und dann nach und nach einzupflegen. Und beim Einpflegen derselbigen habe ich auch schon einige Dinge von anderen zerstoert, so dass auf der Slippy-Map Strassenteile nicht mehr sichtbar waren (mein beliebtester Fehler ist layer=+1 statt layer=1). Die Aenderung von gesperrten Wegeigenschaften erfolgt erst nachdem ein Dialog mit einer Warnmeldung positiv bestaetigt wurde. Oder, der Benutzer der die Relation anlegt wird automatisch ein Mitglied der Relation mit der Rolle 'editor', weiteren Mitgliedern kann das Aendern gestattet werden, in dem sie mit in die Relation aufgenommen werden und ihnen die Rolle 'editor' zugewiesen wird. Voraussetzung ist dafuer, dass Benutzer(-IDs) Mitglied einer Relation werden koennen. ... und dass die Low-Level-API diese Art von Sperren dann auch umsetzt, denn notfalls kann ich mit einfachen REST-Anfragen sehr leicht viel Unheil anrichten! [...] Das sind nur ein paar Ideen, sollte jemand der Meinung sein, dass sich etwas sinnvoll daraus entwickeln laesst, wuerde ich eine 'Relations/Proposed/Lock'- oder 'Relations/Proposed/Locking'-Wikiseite anlegen, auf der man diese und weitere Ideen diskutieren koennte. Prinzipiell eine gute Idee, aber ich bin mir nicht so ganz sicher, ob Sperren der richtige Weg ist oder nicht doch eher so etwas wie eine Freigabe von Aenderungen nach einem Review der fuer ein Gebiet und/oder fuer einen Object-Typ Verantwortlichen. Mit letzterem sperrt man niemanden aus, da die Aenderungen vorlaeufig aber dennoch sichtbar sind, sondern sorgt nur dafuer, dass Aenderungen einen Review-Prozess durchlaufen, bevor sie permanent werden. Und wenn sich fuer ein Gebiet niemand als Reviewer findet, wenn sich also niemand verantwortlich und/oder auf den Schlips getreten fuehlt, dann darf wie bisher wild geaendert werden. Ich hege aber Zweifel, ob dies per Relations geloest werden sollte oder nicht gleich in die OSM-API und die Datenbank rein muss, damit _alle_ Editoren diese Freigabe (oder Sperren) implementieren. Ansonsten wird es sicherlich bald dieselben Klagen wie jetzt geben ... Gruss, -bernd ___ 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.
Sven Anders schrieb: Am Sonntag, 20. Januar 2008 09:23 schrieb Juergen Buchner: Hallo, kannst Du das auch wieder rückgäng machen? Im Rhein-Main Gebiet ist das Ergebnis nicht so besonders prickelnd, weil es jetzt sehr viele Orte doppelt gibt. Ja, es gäbe die Möglichkeit, alle Orte so zu deaktivieren, dass sie nicht mehr angezeigt werden. (Natürlich gebe es auch die Möglichkeit alles zu löschen, aber ich habe im Moment nicht das Gefühl, das das die Meinung in der OSM Gemeinschaft ist). Mmmh. Hier im Kieler Raum ist auch alles mögliche doppelt und es ist mühsam zwischen all den grünen Punkten, die zum Teil schon vorhanden sind, den zu finden, der nun zusätzlich vorhanden ist, um ihn zu löschen. Da zum Teil die Namen auch noch mit Zusätzen sind, würde ich hauptsächlich Deine Punkte löschen. Ich habe hier eher das Gefühl, dass der Import mehr Arbeit macht, als er mir abnimmt. -- Gruß Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach! *kotz*
Hallo, Und sie ziehen zum naechsten spannenden Projekt weiter, wenn die eigene Gegend komplett scheint (um Hausnummern und die Oeffnungszeiten einer Baeckerei einzutragen, braucht man ja keine Gadgets) oder wenn irgendwann mal jeder ein GPS hat. Early Adopters halt. Die sind immer wichtig. Die gibt es, aber es gibt auch andere, die einfach am Thema interessiert sind und deren Interesse hört ganz sicher nicht dann auf, wenn die Gegend um die Ecke erfasst ist. Dann verschieben sich eben die Themenschwerpunkte und man macht auf einer anderen Ebene mit. Stimmt nicht. Diese Leute *werden* weiterziehen, weil es sie eben gerade reizt, etwas neues aufzubauen, und nicht, etwas bestehendes zu pflegen. OSM ist noch ganz lange 'neu' oder besser jung, so wie auch andere Projekte wie KDE lange jung bleiben, wenn man ihnen die Chance lässt, sich zu entwickeln. Die kommerzielle Konkurrenz bleibt ja auch nicht stehen und entwickelt neue Konzepte. Da ist derzeit 3D ganz gross angesagt. Wir saehen ganz schoen alt aus, wenn wir davon ausgehen muessten, den Bach runterzugehen, wenn diese Leute sich ein anderes Hobby suchen - denn das werden sie tun. Wie jedes andere Produkt auch, wird OSM zunehmend nicht mehr fuer Early Adopters interessant sein, und das hat nichts mit Qualitaetsmaengeln zu tun. Von jedem Projekt springen mal Leute ab und wenn die Basis stimmt, wird das problemlos kompensiert. Aber ich sehe das Thema OSM etwas vielschichtiger und sehe das Ziel von OSM nicht nur darin, einen grossen Datenhaufen in der DB zu generieren, der irgendwann 'fertig' ist. Wenn man einen Gegenpol zu den Kommerziellen bilden will, braucht man viel mehr als nur die Daten. Man braucht KnowHow und Leute, die das KnowHow halten und weiterentwickeln. Man braucht Qualitätssicherung und Applikationsschnittstellen. Nicht mit perfekten Werkzeugen, im Gegenteil, aber mit einem Mehrfachen der Zeit, die wir heute investieren (nicht, weil jeder einzelne viel machen wuerde, sondern weil es so viele sind). Die vielen kommen und gehen, aber der das Potential derer, die sich wirklich für digitale Karten und die Technik dahinter interessieren ist und bleibt begrenzt. Grüsse Hubert -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ 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.
In-Reply-To: [EMAIL PROTECTED] On 2008-01-21 13:41, Steffen Voß wrote: Mmmh. Hier im Kieler Raum ist auch alles mögliche doppelt und es ist mühsam zwischen all den grünen Punkten, die zum Teil schon vorhanden sind, den zu finden, der nun zusätzlich vorhanden ist, um ihn zu löschen. Da zum Teil die Namen auch noch mit Zusätzen sind, würde ich hauptsächlich Deine Punkte löschen. Die Anzahl der Fehlermoeglichkeiten in der Region sollte ueberschaubar sein. http://fa-technik.adfc.de/code/opengeodb.pl?locid=469;c=DE;distance=20 liefert in einem Umkreis von 20 km um Kiel: Blumenthal, Holstein Brügge, Holstein Bredenbek bei Rendsburg Dobersdorf, Holstein Emkendorf bei Rendsburg Fahren, Holstein Felde, Holstein Hoffeld bei Bordesholm Kühren bei Preetz Klausdorf / Kiel Krummbek, Holstein Langwedel, Holstein Lehmkuhlen bei Preetz Lindau bei Kiel Osdorf bei Kiel Ottendorf bei Kiel Pohnsdorf bei Preetz Preetz, Holstein Rastorf, Holstein Reesdorf bei Kiel Rodenbek bei Kiel Schönberg (Holstein) Schönhorst, Holstein Schönkirchen, Holstein Schellhorn bei Preetz Schierensee, Holstein Schinkel bei Gettorf Selent, Holstein Stein bei Laboe Strande, Holstein Wahlstorf bei Preetz Warnau bei Nettelsee Wisch bei Kiel Schoenen Gruss Martin -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ 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.
Hi! Steffen Voß schrieb: Ich habe hier eher das Gefühl, dass der Import mehr Arbeit macht, als er mir abnimmt. Bei mir ist es auch einiges an Arbeit. Auf der anderen Seite spart es langfristig viel Arbeit, wenn die Autoupdate-Funktion zB für Bevölkerung funktioniert. Obwohl ich mir vorstellen könnte, das man langfristig für solche Wartungsarbeiten auch eine entsprechendes Frontend für die OSM-Datenbank schafft. Ich denke, der Impost sollte auf jeden Fall optimiert werden: - keine doppelten Nodes, nur weil in OpenGeoDB ein Name mit Zusatz versehen ist - auch da wo noch kein Node existiert, sollten die Zusätze weglassen werden, wenn sie nicht zur offiziellen Bezeichnung eines Ortes gehören, wie zB bei Frankfurt am Main - die is_in Daten aus OpenGeoDB gefallen mir nicht. Auf Stadt/Kreis-Ebene sind sie ungenau. ZB in meiner Ecke steht bei Mistelbach is_in=Bayreuth,... obwohl Mistelbach nicht Teil Bayreuths, sondern des Landkreis Bayreuths ist. Ebene der Regierungsbezirke: Auch hier habe ich zB is_in=...,Braunschweig... gesehen, was wenn überhaupt Regierungsbezirk Braunschweig heißen müsste. Außerdem sind die Regierungsbezirke in Nds abgeschafft soweit ich weiß. -bei mir in Bayreuth taucht Bayreuth jetzt zweimal auf. Der neue Node ist wohl wegen des gleichnamigen Landkreises aufgetaucht, vermutete ich aufgrund der FAQ. Er enthält aber folgenden Tag: openGeoDB:type=Stadt. Den gleichen Tag erhielt auch der bereits bestehende Node. Vermute, hier liegt auch ein inkonsistenter Import vor. Bloß meine Anregungen. Grundsätzlich halte ich den Import für eine gute Sache, besonders weil auch viele Ortsnamen reinkommen, die wir vorher überhaupt nicht hatten. Herzlichst! Nils ___ 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.
Roland Ramthun schrieb: Was haltet ihr davon einen Link aus http://wiki.openstreetmap.org/index.php/User:OpenGeoDB#FAQ in ein Tag der aus der OpenGeoDB gezogenen Orte/Bereiche reinzuschreiben? Das hielte ich auch für eine gute Sache...kann man später ja auch wieder rauslöschen, wenn es allgemein bekannt geworden ist. Man kann ja wirklich nicht erwarten, dass jeder hier mitliest. Es fehlt halt irgendwie auch eine Möglichkeit, über wichtige Neuerungen zu informieren. Nils ___ 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 OpenStreetMa p ist durchgelaufen.
Am Montag, 21. Januar 2008 16:00 schrieb Nils Reuter: Roland Ramthun schrieb: Was haltet ihr davon einen Link aus http://wiki.openstreetmap.org/index.php/User:OpenGeoDB#FAQ in ein Tag der aus der OpenGeoDB gezogenen Orte/Bereiche reinzuschreiben? Das hielte ich auch für eine gute Sache...kann man später ja auch wieder rauslöschen, wenn es allgemein bekannt geworden ist. Man kann ja wirklich nicht erwarten, dass jeder hier mitliest. Es fehlt halt irgendwie auch eine Möglichkeit, über wichtige Neuerungen zu informieren. Ich finde die Idee auch gut. Wenn ich wieder importiere werde ich das ergänzen. Gruß Sven ___ 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.
Bei mir ist es auch einiges an Arbeit. Auf der anderen Seite spart es langfristig viel Arbeit, wenn die Autoupdate-Funktion zB für Bevölkerung funktioniert. Gerade das stelle ich mir gar nicht so prickelnd vor ;) Wollen wir wirklich eine gemeinde stur erst dann als town rendern, wenn die 10.000er grenze überschritten ist? All diese willkürlich festgelegten zahlen sollte man auch weiterhin mit gesundem menschenverstand beurteilen und ggf. regional abweichend interpretieren können. Beispielsweise Heroldsberg bei N sollte weiterhin als town auftauchen, auch wenn 10.000 (noch) nicht ganz erreicht ist... Gibts in der OpenGeoDB nicht auch ein Feld für die administrative Ebene? Das wäre meines Erachtens schon besser geeignet. Gruß, Wabba ___ 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.
Daniel Schmidt wrote: Gibts in der OpenGeoDB nicht auch ein Feld für die administrative Ebene? Das wäre meines Erachtens schon besser geeignet. opengeodb bietet einen sog. Typ - dort lässt sich explizit angeben, ob ein Eintrag einen Stadt-Status hat. Andere Angaben sind z.B. Markt, Flecken, aber auch kompliziertere Dinge wie Universitätsstadt, Landeshauptstadt usw. Das meiste davon stammt aus offiziellen Quellen. Gerade bei Gemeindeauflösungen findet sich dort aber auch der Hinweis ehem. Gemeinde, speziell um nachzuprüfen, ob dieser Eintrag überhaupt noch existiert (als Ort oder Ortsteil) oder ganz aufzuheben ist. 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] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Daniel Schmidt schrieb: Bei mir ist es auch einiges an Arbeit. Auf der anderen Seite spart es langfristig viel Arbeit, wenn die Autoupdate-Funktion zB für Bevölkerung funktioniert. Gerade das stelle ich mir gar nicht so prickelnd vor ;) Wollen wir wirklich eine gemeinde stur erst dann als town rendern, wenn die 10.000er grenze überschritten ist? All diese willkürlich festgelegten zahlen sollte man auch weiterhin mit gesundem menschenverstand beurteilen und ggf. regional abweichend interpretieren können. Beispielsweise Heroldsberg bei N sollte weiterhin als town auftauchen, auch wenn 10.000 (noch) nicht ganz erreicht ist... Gibts in der OpenGeoDB nicht auch ein Feld für die administrative Ebene? Das wäre meines Erachtens schon besser geeignet. Gruß, Wabba ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de Hallo, die Einwohneranzahl ist sicherlich ein geeigneteres Krititerium zur Einteilung town/village als im Mittelalter verliehene Stadtrechte. Die kleinste Stadt Bayern's Rothenfels (population=1006) erscheint nach dem OpenGeoDB-Import auch in hoher Zoomstufe http://informationfreeway.org/?lat=49.89518409739646lon=9.60842345916525zoom=12layers=B000F000F da es als town getaggt wurde. Im Mittelalter war das sicherlich angebracht. Wir erstellen aber Karten für die Gegenwart. Und da ist die Bedeutung von Rothenfels gleichbedeutend mit anderen Orten vergleichbarer Einwohnerzahl, sollte also mit village getaggt werden. Gleiches gilt für den ehemaligen Grafensitz 97794 Rieneck (population=2112). Auch hier wäre village angebrachter als town. Gruß Thomas ___ 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.
Karl Eichwalder schrieb: Bei mir ist es auch einiges an Arbeit. Auf der anderen Seite spart es langfristig viel Arbeit, wenn die Autoupdate-Funktion zB für Bevölkerung funktioniert. Gerade das stelle ich mir gar nicht so prickelnd vor ;) Wollen wir wirklich eine gemeinde stur erst dann als town rendern, wenn die 10.000er grenze überschritten ist? Das hat ja niemand gesagt. Die Bevölkerungszahl in den Daten zu haben hat ja nichts mit der Einordnung village/town/city zu tun. Ist einfach ein zusätzliches Feature. Die Bedeutung des Orts kann davon unabhängig beurteilt werden. (ggf halt bei autoupdate den Wert place herausnehmen) Nils ___ 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.
Nils Reuter [EMAIL PROTECTED] writes: - keine doppelten Nodes, nur weil in OpenGeoDB ein Name mit Zusatz versehen ist - auch da wo noch kein Node existiert, sollten die Zusätze weglassen werden, wenn sie nicht zur offiziellen Bezeichnung eines Ortes gehören, wie zB bei Frankfurt am Main Da stimme ich auch zu, wobei ich diese Langnamen in einem anderen Tag schon behalten wollte (name:extended z.B.) - ein Suchwerkzeug koennte die optional anzeigen, um die Auswahl bei mehreren Treffern zu erleichtern. Die Langnamen mit raeumlichen Bezug (Gehren bei Ilmenau) sind aber wohl besser durch eine Umkreissuche zu machen. Cheers Colin ___ 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.
Na ja, Offenbar ist etwas mit den sonderzeichen schiffgegangen: in beide Kantone Genève und Neuchâtel waren *alle* Dorfname doppelt (Corsier,Corsier). Ich habe zwar alles korrigiert (100), aber bitte, habt ein bischen Sorge für die OSM-Gnomen... Und jetzt erscheinen in Osmarender die Bezirke, die kaum Bedeutung in der Schweiz haben (aussen Graubünden) Gruss aus Welschland Marc Le 19 janv. 08 à 21:59, Sven Anders a écrit : Moin, Ich habe mich dazu entschieden, gemäß den Open Source Regeln Release Early, Release Often den Import von OpenGeoDB in OpenStreetMap an zu werden. Er wurde heute um 18:16 Uhr gestartet und war um ca. 21:53 Uhr beendet. Leider ist der Import von Relationen zum Teil fehlgeschlagen. Grund dafür ist vermutlich ein Bug im Zusammenspiel zwischen Josm und dem Import- Bot (oder ein Bug bei Josm). Ich habe mich deshalb dafür entschieden alle noch nicht hochgeladen Relationen (=fast alle!!) aus dem Import zu entfernen und später zu ergänzen. Bitte schaut Euch die daraus neu entstanden Orte an. Ich hoffe es ist nichts kaputt gegangen, ansonsten bitte möglichst schnell melden, damit ich sehen kann, wie wir es wieder gerade biegen (ich habe ein Backup aller places vor dem Lauf) Kommentare (ich hoffe das es im Großen und Ganzen gefällt) dazu könnt Ihr auf die Webseite: http://wiki.openstreetmap.org/index.php/User:OpenGeoDB abgegeben. Ich plane später weitere Abgleiche zwischen OpenGeoDB und OpenStreetmap, dazu muss aber erst das Skript angepasst werden. Gruß Sven ___ 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] Potlach! *kotz*
Hallo, OSM ist noch ganz lange 'neu' oder besser jung, so wie auch andere Projekte wie KDE lange jung bleiben, wenn man ihnen die Chance lässt, sich zu entwickeln. 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. Von jedem Projekt springen mal Leute ab und wenn die Basis stimmt, wird das problemlos kompensiert. Aber ich sehe das Thema OSM etwas vielschichtiger und sehe das Ziel von OSM nicht nur darin, einen grossen Datenhaufen in der DB zu generieren, der irgendwann 'fertig' ist. Wenn man einen Gegenpol zu den Kommerziellen bilden will, braucht man viel mehr als nur die Daten. Man braucht KnowHow und Leute, die das KnowHow halten und weiterentwickeln. Man braucht Qualitätssicherung und Applikationsschnittstellen. Wenn die Daten erstmal da sind, dann kommen die Anwendungsprogram- mierer ganz von allein. Erst ein schoenes Korsett aufbauen und das dann von willigen Arbeitsbienen nach Vorschrift befuellen lassen, das geht halt (hier) nicht. 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. 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... 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. Also meine persoenliche Perspektive ist, dass ich die Userbasis fuer OSM vergroessern will; alles andere faellt, so glaube ich, dann als Nebenprodukt ab. Wenn durch die grossen Userzahlen der Server ploetzlich schleichend langsam wird, DANN wird sich jemand darum kuemmern, und so auch bei anderen Problemen. (Und dann sind wir auch bekannt genug, um Leute anzuziehen, die diese Probleme dann auch loesen koennen und wollen.) 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 ;-) 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] Erster OpenGeoDB Import in OpenStreetMap ist durchgelaufen.
Na ja, Offenbar ist etwas mit den sonderzeichen schiffgegangen: in beide Kantone Genève und Neuchâtel waren *alle* Dorfname doppelt (Corsier,Corsier). Ich habe zwar alles korrigiert (100), aber bitte, habt ein bischen Sorge für die OSM-Gnomen... Und jetzt erscheinen in Osmarender die Bezirke, die kaum Bedeutung in der Schweiz haben (aussen Graubünden) Neben den Bezirken stehen oft mals auch noch die Gemeinden, was ich oft noch für verwirrender halte. Oft besteht eine politische Gemeine aus 2 Orten z.B. bilden die Orte Schönenber und Kradolf die Politische Gemeinde Kradolf-Schönenberg. Nun hats neben den beiden Orten noch einen dritten: http://www.informationfreeway.org/index.php?lat=47.52335062149108lon=9.193408882216625user=studerapzoom=14layers=B000F000F Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
