[Talk-de] Revert / Bulk Uploading fortsetzen
Ich versuche gerade 130.000 nodes/ways DEPHA Daten (wiki.openstreetmap.org/DEPHA) fuer Aethiopien hochzuladen. Folgendes Problem: Der erste Versuch ist nach 2000 nodes stehen geblieben. Changeset: http://www.openstreetmap.org/browse/changeset/2804572 Dieses habe ich mit revert.pl rueckgaengig gemacht - und es schien erfolgreich verlaufen zu sein. Allerdings scheinen die Nodes immernoch in der Datenbank zu sein, oder? Der zweite Versuch ist leider nach 8000 abgebrochen aufgrund eines technischen Problems. Diese Probleme sollten nun ausgemerzt sein (dank screen / Server in Deutschland). Ich benutze bulk_upload.py welches netterweise die schon hochgeladenen IDs zwischenzuspeichern scheint um so ein Fortsetzen zu erlauben. Leider bekomme ich nun einen 404-Error. Ist das ein Server Problem oder ein Bug im Script? ~/depha/bulk_upload_06$ python2.5 bulk_upload.py -i ../depha-import-alex30aug09.osm -u DEPHA Import by AddisMap -p -c DEPHA Import, continue after 8000 nodes Created changeset: 2810686 Uploading to changeset 2810686 Error uploading changeset:404 Viele Gruesse, Alexander ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC-Import startet und braucht eure Hilfe
Marcus Wolschon schrieb: Die Areas sind am einfachsten und deshalb fangen wir mit denen an um für die anderen Erfahrungen zu sammeln. die regierungsbezierke und landkreise in baden-württemberg sind seit gestern abend komplett... aber das ganze ist enorm zeitraubend! da muss eine andere lösung her! insgesamt muss das mehr (halb-)automatisiert werden sonst sinkt das engagement der leute schnell auf ein sehr niedriges maß. es fehlt auch eine vernünftige suchmöglichkeit nach den tmc-entities. die aufteilung in zig seiten im wiki ist eine katastrophe. sinnvoll wäre eine dedizierte webanwendung mit datenbank und anbindung an die minütlichen diffs vom planetfile. so könnten dann auch gleich plausibilitätschecks durchgeführt werden und die bereits getaggten gebiete entsprechend markiert werden. ich habe mit den DONE meldungen im wiki mehr zeit verbracht als mit dem eintragen mit josm... das ist doof. was uns natürlich auch weiterhin fehlt sind die gemarkungsgrenzen der einzelnen städte und gemeinden. @jochen,@frederik gibt es da vielleicht mal wieder eine deutschlandweite datenspende, nachdem die erste mit den kreisgrenzen ja sehr erfolgreich verlief? beim eintragen der tmc-codes können in josm übrigens auch sinnvollerweise gleichzeitig die grenzrelationen sortiert werden und richtig benannt werden. die landkreise in BW waren alle nur mit dem ortsnamen versehen (also z.b Böblingen anstatt Landkreis Böblingen) sofern es nicht Stadtkreise (z.b. Karlsruhe, Stadt) waren oder der Landkreisname sich nicht von einer dominierenden stadt abgeleitet hat (z.b. Schwarzwald-Baar-Kreis). außerdem war der stadtkreis heidelberg nicht auffindbar und ich habe den deswegen neu angelegt. kann das mal bitte jemand überprüfen ob das so passt und der amtliche gemeindeschlüssel stimmt http://www.openstreetmap.org/browse/relation/285864 grüße frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC-Import startet und braucht eure Hilfe
beim eintragen der tmc-codes können in josm übrigens auch sinnvollerweise gleichzeitig die grenzrelationen sortiert werden und richtig benannt werden. die landkreise in BW waren alle nur mit dem ortsnamen versehen (also z.b Böblingen anstatt Landkreis Böblingen) sofern es nicht Stadtkreise (z.b. Karlsruhe, Stadt) waren oder der Landkreisname sich nicht von einer dominierenden stadt abgeleitet hat (z.b. Schwarzwald-Baar-Kreis). Vielleicht solltet ihr euch da endlich mal auf eine gemeinsame vorgehensweise einigen, bevor das große hin und her losgeht. Offiziell hat die Verwaltungsform ja nichts im Namen zu suchen, wenn es nicht Bestandteil des Namens selbst ist, Salzlandkreis z.B. Die Verwaltungsform ergibt sich ja auch eigentlich auch aus dem Admin Level. Mit deiner Umbenennung hast du mindestens schonmal den Grenzcheck von Sven Anders torpediert. Der geht nach den offiziellen Listen, welche keine Verwaltungsform im Namen tragen. Spätestens nach dem nächsten Durchlauf erscheinen die umbenannten Kreise dann wieder als nicht existent. http://svenanders.openstreetmap.de/ags/Deutschland/Baden-Wuerttemberg/Reg_-Bez_Stuttgart/index.html Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, ich habe auf meiner Nutzerseite (http://wiki.openstreetmap.org/wiki/User:Daswaldhorn) eine Liste angefangen, in der irgendwann mal alle Staaten mit ihrer Grenzrelation vertreten sein sollen. Dabei ist mir aufgefallen, daß bei einigen Ländern die Gesamtrelation nur die Relationen der einzelnen Grenzabschnitte enthält (z.B. Frankreich, 11980). Mir würde es lieber gefallen, wenn die Relation direkt die ways enthält, zB. Tschechien, 51684. Warum? - Die API gibt im Falle Frankreichs nur die Relation plus die Unterrelationen, aber nicht die eigentlichen Ways, auch mit /full nicht. Oder kenne ich den Befehl für alles nicht? - Der Relations-Analyzer kann mit diesen verschachtelten Relationen nicht umgehen. Ja ich weiß, wir taggen nicht für den Analyzer, aber der ist halt sehr hilfreich beim Finden von Lücken und sonstigen Fehlern. Was denkt ihr darüber? Sind die Verschachtelungen in Ordnung, oder sollten die Ways direkt in die Relation rein? Grüße, Carsten P.S: Falls jemand so eine Liste kennt, bitte melden, ich habe im Wiki noch nichts gefunden. -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.funpic.de/gpg.html = www.stopptdievorratsdatenspeicherung.de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Revert / Bulk Uploading fortsetzen
Der 404-error ist geklaert... Ich hatte noch nicht hochgeladene nodes (id negativ) mit action=modify. Leider gibt der Server da aber keine ausfuehrlichere Meldung als 404 zurueck. Gruss, Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
hallo carsten, evtl. hilft dir http://wiki.openstreetmap.org/wiki/Boundaries.pl (kann auch nested relations) weiter? oder auch eine solche liste: http://wiki.openstreetmap.org/wiki/Relation_lists könnte ich ggf. mal für europe oder planet laufen lassen... ciao gerhard On Sun, 2009-10-11 at 13:59 +0200, Carsten Gerlach wrote: Hallo, ich habe auf meiner Nutzerseite (http://wiki.openstreetmap.org/wiki/User:Daswaldhorn) eine Liste angefangen, in der irgendwann mal alle Staaten mit ihrer Grenzrelation vertreten sein sollen. Dabei ist mir aufgefallen, daß bei einigen Ländern die Gesamtrelation nur die Relationen der einzelnen Grenzabschnitte enthält (z.B. Frankreich, 11980). Mir würde es lieber gefallen, wenn die Relation direkt die ways enthält, zB. Tschechien, 51684. Warum? - Die API gibt im Falle Frankreichs nur die Relation plus die Unterrelationen, aber nicht die eigentlichen Ways, auch mit /full nicht. Oder kenne ich den Befehl für alles nicht? - Der Relations-Analyzer kann mit diesen verschachtelten Relationen nicht umgehen. Ja ich weiß, wir taggen nicht für den Analyzer, aber der ist halt sehr hilfreich beim Finden von Lücken und sonstigen Fehlern. Was denkt ihr darüber? Sind die Verschachtelungen in Ordnung, oder sollten die Ways direkt in die Relation rein? Grüße, Carsten P.S: Falls jemand so eine Liste kennt, bitte melden, ich habe im Wiki noch nichts gefunden. ___ 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] Strato sponsort 3 Server für OSM
Frederik Ramm frede...@remote.org wrote: Erst einmal recht vielen Dank für Deine ausführliche Stellungnahme :-) Konfigurierbarkeit der Karte Einbindungsmöglichkeit von Anzeigeplugins Einbindungsmöglichkeit von Editierplugins Einbindungsmöglichkeit von verstreuten Inhalten bessere Unterstützung bei der Anzeige von Relationen In diesem Zusammenhang würde ich gern noch noch einige Laienfragen nachschieben, ob Folgendes überhaupt mit den heute zur Verfügung stehenden Mitteln technisch in angemessener Zeit machbar ist: Ist es grundsätzlich überhaupt möglich, statt der fertig gerenderten Karte beim Navigieren durch die Karte direkt die Datenbank anzuzapfen und live auf dem Ziel-PC zu rendern? Wie lange würde es (Pi mal Daumen) dauern, auf einem Durchschnitts Doppelkern PC mit 3GHz einen Bildschirm voll zu rendern und die Daten zu holen? Haben die Daten überhaupt irgendeine Verknüpfung (z.B. Pointer-/Baum- Strukturen oder Schlüssel), so dass räumlich nahe beieinander liegende Daten schneller zugreifbar sind? Oder liegt die Nachbarstraße einer Straße in Hamburg genausoweit entfernt in der Datenbank, wie eine in München oder Lissabon? Wenn ja, könnte dann ein Tool über die Datenbank laufen und entsprechende Verknüpfungen/Strukturen für die bisherige Datenbank erst einmal grundsätzlich aufbauen und später für frisch Hochgeladenes umgehend einbauen? Wäre es im Zusammenhang mit den oben beschriebenen Anforderungen an solch eine Software sinnvoll, eventuell andere freie Projekte anzusprechen, die sich mit Grafik beschäftigen wie z.B. Gimp? Möglicherweise haben die entsprechende Werkzeuge schon zur Hand, die angepssst werden könnten. So bräuchte man hier nicht das Rad von Neuem zu erfinden. Das Gleiche gilt für freie Datenbank Projekte. Müssten für die Anzeige- und Editierplugins nicht zunächst einmal grundsätzliche Überlegungen über das Aussehen einer Schnittstelle angestellt werden, welche die Serversoftware anbieten muss? Kann das ein einzelner Programmierer überhaupt leisten oder müssten da mehrere der diversen Spezial-Karten und -Funktionsanbieter zusammenwirken, um die Anforderungen zusammen zu tragen? Wenn ja, wären vielleicht Veranstaltungen, wie die Fossgis Konferenz ein guter Ort, um dies überhaupt erstmals nach entsprechender Vorankündigung und Vordiskussion zu tun? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] der Ort ist wichtig
vielen Dank für alle Eure Antworten! place=city sollte reichen. Aber bitte nicht machen. ok, bin brav, keine sorge. ein problem bei Wieselburg ist auch, dass es zwei Gemeinden sind: Wieselburg-Stadt und Wieselburg-Land (ist keine Stadt), zusammen machen sie die größte Stadt im Bezirk. und Wieselnburg(-Land) ist meine Heimatgemeinde ;) Diese Ortsnamen (bis auf Ybbs, was man bei Stadt Land Fluss manchmal braucht) h?re ich zum ersten Mal. ja, man lernt auf OSM nie aus! In gr??eren ?bersichten ist t...@h da insgesamt etwas eigen in der Auswahl. Westdeutschland in Zoomstufe 7 ist derzeit durch D?sseldorf, Leer, Schwerte, Paderborn, Gie?en, Pforzheim und Kaiserslautern wiedergegeben. Die gr??ten St?dte K?ln, Frankfurt am Main, Stuttgart, Dortmund und Essen hingegen fehlen. nicht gut, das mindert die Qualität! Einwohnerzahlen spielen keine Rolle, nur die Abstufung city, town, village. ok. verstanden. wie dann weiterdifferenziert wird hängt vom platz ab oder wie? Scheibbs ist die Bezirkshauptstadt (4304), Wieselburg eine Stadt (3693) und Purgstall ein Markt (5322) im Bezirk Scheibbs, Einwohner in Klammern. Ich hab's mir noch nicht angeschaut, mglw. mu? man da mit place=town und der Platzierung der place-Tags ein wenig spielen. zum spielen habe ich noch zu wenig erfahrung/mut. lieber auf der mailingliste fragen... Insgesamt eher ein in OSM unter-abgedeckter Bezirk in N?. kann sein, ich arbeite daran, das zu ändern! :) N.B. an Thomas Steiner: kennst Du talk-at? Solche ?sterreich-spezifische Fragen sind dort wohl besser aufgehoben... ;) nein, ich werde dort weiterdiskutieren! danke! Mapnik ist auch nicht viel besser: Ab Zoomlevel 8 wird Berlin von Brandenburg verdr?ngt. das ist aber gar nicht gut: sowas amcht die Qualität und Brauchbarkeit der Karte kaputt... Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Irgendwas läuft schief in der POI-Welt !
Martin Koppenhoefer dieterdre...@gmail.com wrote: auch wenn das Ganze im ersten Moment wie eine gute Idee klingt, denke ich doch, dass sie contraproduktiv wäre: 1. wenn man alle Änderungen mitzählt, würden die hardcore-Sternchensammler vermutlich zu Punkte-verschiebern (im Kleinstbereich) werden 2. wenn man nur neue Wege zählt, würde evtl. die history leiden (Wege löschen und neuzeichnen). Die Sprüche waren meinerseits nur so aus dem Handgelenk dahingepinnt und sollten lediglich die Stoßrichtung deutlich machen. Das System müsste natürlich wasserdicht sein. Letztendlich wird es daran scheitern, dass niemand die Lust haben wird, sich darum zu kümmern. Ich würde ehrlich gesagt die Krätze kriegen, wenn ich mich ständig in diesen Seichtgebieten rumtreiben müsste. Oder sollte vielleicht doch jemand mit Ambitionen im Marketingbereich ... ? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude über Straße
Simon Kokolakis schrieb: C. Brause schrieb: Mein Versuch war jetzt, das Gebäude dreizuteilen und den Abschnitt, der über die Straße geht als Layer=1 zu taggen. Funktionierte nur leider nicht... Was genau funktionierte nicht? Hat der Editor den tag verweigert oder wie? Der Editor (Merkaartor) hatte nichts dagegen das aufzunehmen. Aber es wurde (zumindest von Mapnik, bei Osmarender bin ich mir grad unsicher) nicht entsprechend gerendert. Ich hatte es zwischendurch inzwischen als Tunnel getagt, habs aber vorhin wieder nur auf layer=1 zurückgeändert. Mapnik hats inzwischen wieder aktualisiert, osmarender noch nicht, so wie ich das sehe. Hat jemand mal ein Beispiel für solch eine Konstellation, die mit building=yes und layer=1 und ohne bridge/tunnel Tag gerendert wurde? http://www.openstreetmap.org/?lat=53.049029lon=8.63158zoom=18layers=B000FTF Es handelt sich um das Gebäude, das über die Bebelstraße führt. Die Straße wird trotz layer=1 über das Gebäude gezeichnet. Bevor jetzt irgendjemand sagt Es wird nicht für die Renderer gemapt: Ich denke ohne Renderer wäre das Projekt relativ sinnlos. Und die wichtigsten (bekanntesten) Renderer sind Mapnik und Osmarender. Wenn das Projekt zuspruch bei Usern bekommen will, muss die Darstellung DA funktionieren. Das ist meine Meinug dazu. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Gary68 g...@gary68.de wrote: mein nokia e51 lädt während der fahrt die daten vom nokia server und rendert sie. also wird ein doppelkern 3ghz nur lachen und sich totlangweilen. Ahja, danke für die Info. Aber dann frage ich mich, wieso Potlatch mitunter Minuten braucht, um ein neues Bild aufzubauen, wenn ich durch die Karte navigiere. Liegt es daran, dass der Renderprozess eventuell nichr auf meinem Rechner durchgeführt wird? Und angesichts dessen, dass das Nokia mobil surft, wird es wohl nicht daran liegen, dass hier nur DSL 2000 verfügbar ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude über Straße
Am 11. Oktober 2009 15:40 schrieb C. Brause chr_bra...@gmx.de: Bevor jetzt irgendjemand sagt Es wird nicht für die Renderer gemapt: Ich denke ohne Renderer wäre das Projekt relativ sinnlos. Und die wichtigsten (bekanntesten) Renderer sind Mapnik und Osmarender. Wenn das Projekt zuspruch bei Usern bekommen will, muss die Darstellung DA funktionieren. Wie alles sind natürlich auch die Renderregeln nicht perfekt, sondern ständiger Fortschreibung und Optimierung unterworfen. Wenn man den Eindruck hat, dass es an einer bestimmten Stelle noch nicht wie gewünscht funktioniert, ist die beste Variante, die Regeln anzupassen (bzw. einen entsprechenden Vorschlag einzureichen). Die zweitbeste ist, hier auf der Liste nach Meinungen zu fragen und ggf. dann einen Eintrag im trac zu machen, auf dass evtl. jemand anderes die Regeln anpasst. So wird auch dokumentiert, wo noch Probleme bestehen, so dass ggf. auch erst nach einiger Zeit sich jemand des Problems annimmt. Die URL ist: trac.openstreetmap.org Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
potlatch ist in flash geschrieben aber abgesehen davon denke ich, dass die meiste zeit mit datenladen zugebracht wird. On Sun, 2009-10-11 at 15:49 +0200, Tirkon wrote: Gary68 g...@gary68.de wrote: mein nokia e51 lädt während der fahrt die daten vom nokia server und rendert sie. also wird ein doppelkern 3ghz nur lachen und sich totlangweilen. Ahja, danke für die Info. Aber dann frage ich mich, wieso Potlatch mitunter Minuten braucht, um ein neues Bild aufzubauen, wenn ich durch die Karte navigiere. Liegt es daran, dass der Renderprozess eventuell nichr auf meinem Rechner durchgeführt wird? Und angesichts dessen, dass das Nokia mobil surft, wird es wohl nicht daran liegen, dass hier nur DSL 2000 verfügbar ist. ___ 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] der Ort ist wichtig
Am 11. Oktober 2009 15:00 schrieb Thomas Steiner finbref.2...@gmail.com: ok. verstanden. wie dann weiterdifferenziert wird hängt vom platz ab oder wie? evtl. ja, mapnik hat jedenfalls prinzipiell ein feature, um die Größe einer Area zu berücksichtigen. Näheres wie gesagt im Stylesheet (s.o.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo Gerhard, Am Sonntag 11. Oktober 2009 14:43:09 schrieb Gary68: oder auch eine solche liste: http://wiki.openstreetmap.org/wiki/Relation_lists könnte ich ggf. mal für europe oder planet laufen lassen... Das wäre fein, wenn du das nur für admin_level=2 machen könntest. Grüße, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.funpic.de/gpg.html = www.stopptdievorratsdatenspeicherung.de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, Carsten Gerlach wrote: ich habe auf meiner Nutzerseite (http://wiki.openstreetmap.org/wiki/User:Daswaldhorn) eine Liste angefangen, in der irgendwann mal alle Staaten mit ihrer Grenzrelation vertreten sein sollen. Voruebergehend eventuell hilfreich; langfristig darf niemand davon ausgehen, dass Relations-IDs konstant bleiben. Ich koennte jederzeit eine Relation loeschen und neu anlegen, dann haette sie eine neue ID. Dabei ist mir aufgefallen, daß bei einigen Ländern die Gesamtrelation nur die Relationen der einzelnen Grenzabschnitte enthält (z.B. Frankreich, 11980). Mir würde es lieber gefallen, wenn die Relation direkt die ways enthält, zB. Tschechien, 51684. Das skaliert nicht so gut, denn es gibt Laender, bei denen dieses Verfahren Relationen von nicht mehr handhabbarer Groesse hervorbringt. Du musst also auf jeden Fall auch mit kaskadierenden Relationen umgehen koennen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Hallo, Ist es grundsätzlich überhaupt möglich, statt der fertig gerenderten Karte beim Navigieren durch die Karte direkt die Datenbank anzuzapfen und live auf dem Ziel-PC zu rendern? Haben andre ja schon geschrieben: Engpass ist hier die Datenbank. Wie lange würde es (Pi mal Daumen) dauern, auf einem Durchschnitts Doppelkern PC mit 3GHz einen Bildschirm voll zu rendern und die Daten zu holen? Wenn Du eine Datenbank lokal hast, die nur fuer Dich da ist und sonst nichts zu tun hat, dann kannst Du einen Bildschirm voll mit Mapnik in einer Sekunde rendern. Daran liegt es also nicht - die Daten allerdings alle zu holen und uebers Netz zu uebertragen, das kann schon laenger dauern, besonders dann, wenn man mehr als nur ein grobes Strassennetz haben will, und besonders dann, wenn man nicht nur einen Haeuserblock, sondern eine ganze Grossstadt anzeigt. Haben die Daten überhaupt irgendeine Verknüpfung (z.B. Pointer-/Baum- Strukturen oder Schlüssel), so dass räumlich nahe beieinander liegende Daten schneller zugreifbar sind? Oder liegt die Nachbarstraße einer Straße in Hamburg genausoweit entfernt in der Datenbank, wie eine in München oder Lissabon? Wenn ja, könnte dann ein Tool über die Datenbank laufen und entsprechende Verknüpfungen/Strukturen für die bisherige Datenbank erst einmal grundsätzlich aufbauen und später für frisch Hochgeladenes umgehend einbauen? In der normalen Datenbank auf dem Server liegen die Daten kreuz und quer, aber es gibt natuerlich Datenbank-Indizes, die raeumlich beieinanderliegendes auch zusammensortieren. In einer zum Rendern aufbereiteten Datenbank (wie z.B. fuer Mapnik) ist das sogar noch deutlicher, da dort auch die Ways schon geometrisch sortiert sind (normal nur die Nodes). Es gibt aber auch Datenbanken, die fuer spezielle Zwecke optimiert sind, so wie z.B. ROMA und TRAPI. Zumindest bei TRAPI liegen die OSM-Dateien fuer bestimmte Gebiete tatsaechlich als einzelne Files auf der Platte. Wäre es im Zusammenhang mit den oben beschriebenen Anforderungen an solch eine Software sinnvoll, eventuell andere freie Projekte anzusprechen, die sich mit Grafik beschäftigen wie z.B. Gimp? Sehe ich nicht - zu unterschiedliche Anforderungen, und wie gesagt, bei uns gehts eher darum, die richtigen Daten schnell zu laden, als diese dann grafisch anzuzeigen. Möglicherweise haben die entsprechende Werkzeuge schon zur Hand, die angepssst werden könnten. So bräuchte man hier nicht das Rad von Neuem zu erfinden. Das Gleiche gilt für freie Datenbank Projekte. Unterschaetze jedoch nicht den Aufwand solcher Kommunikation. Ist ja nicht so, dass die dann sagen: Prima, ich hab nur drauf gewartet, dass jemand fragt, hier hab ich schon die Loesungen fuer alle Probleme ;-) Müssten für die Anzeige- und Editierplugins nicht zunächst einmal grundsätzliche Überlegungen über das Aussehen einer Schnittstelle angestellt werden, welche die Serversoftware anbieten muss? Kann das ein einzelner Programmierer überhaupt leisten oder müssten da mehrere der diversen Spezial-Karten und -Funktionsanbieter zusammenwirken, um die Anforderungen zusammen zu tragen? Wenn ja, wären vielleicht Veranstaltungen, wie die Fossgis Konferenz ein guter Ort, um dies überhaupt erstmals nach entsprechender Vorankündigung und Vordiskussion zu tun? Grundsaetzlich bin ich auch ein Freund von in einem Zimmer zusammensitzen und was gemeinsam erledigen. Allerdings ist es nach meiner Erfahrung so, dass man bei sowas immer dann relativ gute Chancen hat, wenn man das Thema innerhalb von 1-2 Tagen abschliessend behandeln kann, oder zumindest so weit, dass klar ist: Du machst jetzt zu Hause noch dies, ich mach das, er macht jenes, und uebermorgen kuendigen wir es auf der Mailingliste an. - Wenn man stattdessen hochliegenden Strategiesitzungen macht, bei denen man Vorbereitungen fuer Konzepte fuer Designs fuer Datenbank-Interfaces durchfuehrt, dann ist das oftmals zu abstrakt und fuehrt zu nichts. Fuer Dinge, die noch so un-konkret sind, ist es wohl besser, 1-3 Leute, denen die Sache am Herzen liegt, tun sich zusammen und basteln was, ohne lang rumzudiskutieren. Es kann ja auch erstmal nur eine kleine Loesung sein, die man spaeter eventuell ausbaut. Also konkret, lieber erstmal ein funktionierendes Anzeige-/Edit-Plugin mit bescheuerter Oberflaeche und spaeter macht es jemand huebsch, als dass man wochenlang im Malprogramm irgendwas malt und bastelt und diskutiert, und nachher setzt es niemand um. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Irgendwas läuft schief in der POI-Welt !
Tirkon schrieb: Dasselbe trifft übrigens auch bei Wikimedia Commons für die georeferenzierten Fotos zu, die wir hier jetzt auch direkt nutzen können: http://wiki.openstreetmap.org/wiki/DE:Wiki_Help#Bilder_aus_Wikimedia_Commons_einbinden Auch hier fragt man sich, warum User ihre teils erstklassigen Fotos akribisch georeferenzieren und dann der propietären Verwendung anheim stellen. Der freie Dienst hat das Nachsehen. Ich dachte, Wikimedia ist schon frei? Die Zeile A database of 5,183,484 freely usable media files to which anyone can contribute. suggeriert das zumindest. Hm? roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Irgendwas läuft schief in der POI-Welt !
Roland Spielhofer rsp...@gmx.net wrote: Ich dachte, Wikimedia ist schon frei? Die Zeile A database of 5,183,484 freely usable media files to which anyone can contribute. suggeriert das zumindest. Hm? Das war jetzt vielleicht etwas missverständlich. Das Problem ist eben, dass viele Leute !!nicht!! bei Wikimedia Commons hochladen, sondern bei anderen proprietären Bilderdiensten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Carsten Gerlach wrote: P.S: Falls jemand so eine Liste kennt, bitte melden, ich habe im Wiki noch nichts gefunden. könntest du das nicht aus der DB lesen? zum Beispiel sind das alle, die eine geschlossene Relation haben. Bei den anderen fehlt in der Regel die Seegrenze. select (osm_id*-1) as id, name, name:en as name_en from planet_osm_polygon where osm_id 0 AND admin_level='2' Total query runtime: 133 ms. 60 rows retrieved. 52939;Føroyar;Faroe Islands 62269;Isle of Man; 9407;Andorra; 36990;Monaco; 252426;International Border - Russia - Georgia; 53293;Македонија;Macedonia 88206;Lesotho; 195269;Burundi;Burundi 88210;Swaziland; 195290;Malawi;Malawi 192800;Ethiopia;Ethiopia 87132;South Africa; 80500;Australia; 59470;Brasil;Brazil 184888;UNDOF; 178009;Кыргызстан;Kyrgyzstan 192783;Burkina Faso;Burkina Faso 87565;South Africa; 192788;Chad;Chad 192790;Central African Republic;Central African Republic 195271;Zambia;Zambia 195272;Zimbabwe;Zimbabwe 195274;Botswana;Botswana 192785;Mali;Mali 192786;Niger;Niger 49903;Laos national border; 240157;Cailloux à Malvillain; 157060;Algérie (Côte Méditerannéene); 218657;Slovenija;Slovenia 54624;San Marino; 36989;Città del Vaticano; 161033;Монгол улс;Mongolia 51499;Liechtenstein; 171496;Rwanda;Rwanda 184629;Bhutan; 184633;Nepal; 192796;Uganda;Uganda 214626;Тоҷикистон;Tajikstan 252645;Bolivia; 60189;Российская Федерация;Russian Federation 72594;Latvia; 214885;Croatia; 28711;Luxembourg; 47796;Nederland;The Netherlands 50046;Danmark;Denmark 51684;Česká Republika;Czech Republic 51701;Switzerland;Swiss Confederation 58974;Moldova;Moldova, rupublic of 62149;United Kingdom; 62273;Ireland; 184818;Jordan;Jordan 49715;Polska;Poland 51239;Deutschland - Schweiz; 59065;Республика Беларусь;Republic of Belarus 192797;Elemi Triangle; 48130;Italia;Italy 51477;Deutschland;Federal Republic of Germany 52411;België - Belgique - Belgien;Belgium 60199;Україна;Ukraine 148838;United States of America; Die offenen Wege: select distinct (osm_id*-1) as id, name, name:en as name_en from planet_osm_line where osm_id 0 AND admin_level='2' Total query runtime: 222 ms. 137 rows retrieved. 9407;Andorra; 14296;Slovakia; 16239;Austria;Austria 16483;Slovenija; 17511;Deutschland - Österreich; 21335;Magyarország;Hungary 28711;Luxembourg; 36989;Città del Vaticano; 36990;Monaco; 47796;Nederland;The Netherlands 48130;Italia;Italy 49715;Polska;Poland 49865;Thailand national border; 49898;Cambodia national border; 49903;Laos national border; 49915;Vietnam national border; 50371;Burma national border; 51239;Deutschland - Schweiz; 51684;Česká Republika;Czech Republic 51701;Switzerland;Swiss Confederation 52411;België - Belgique - Belgien;Belgium 52822;Sweden;Sweden 52823;Norge;Norway 52939;Føroyar;Faroe Islands 53292;Shqipëria;Albania 53294;Србија;Serbia 53296;Crna_Gora;Montenegro 54224;Finland; 54624;San Marino; 58974;Moldova;Moldova, rupublic of 59065;Республика Беларусь;Republic of Belarus 59470;Brasil;Brazil 59525;HR - SR; 60189;Российская Федерация;Russian Federation 60199;Україна;Ukraine 62149;United Kingdom; 62269;Isle of Man; 62273;Ireland; 65212;Deutschland - Tschechien; 65227;Deutschland - Polen; 72594;Latvia; 72596;Lithuania; 79510;Estonia; 79981;France-territorial waters; 85764;România;Romania 87132;South Africa; 87565;South Africa; 88206;Lesotho; 88210;Swaziland; 90689;România;Romania 91917;Lithuania; 92863;España; 102647;Italia - Schweiz; 102666;Österreich - Schweiz; 102877;Österreich - Liechtenstein; 102882;Schweiz - Liechtenstein; 102885;Italia - Österreich; 102898;Österreich - Česko; 108089;Ecuador; 114685;United States of America; 114686;Mexico; 120027;Colombia; 148837;Canada; 148838;United States of America; 157060;Algérie (Côte Méditerannéene); 161033;Монгол улс;Mongolia 164802;България;Bulgaria 167454;Chile; 171496;Rwanda;Rwanda 174737;Türkiye;Турк 178009;Кыргызстан;Kyrgyzstan 184629;Bhutan; 184633;Nepal; 184640;Bangladesh; 184818;Jordan;Jordan 184840;Syria;Syria 184843;Lebanon;Lebanon 184888;UNDOF; 186382;България;Bulgaria 192307;Ελλάδα;Greece 192691;Morocco; 192734;North Korea; 192756;Algérie;Algeria 192757;تونس;Tunesia 192758;Lībiyā;Libya 192761;Egypt;Egypt 192763;Mauritania;Mauritania 192774;Gambia;Gambia 192775;Senegal;Senegal 192776;Guinea-Bissau;Guinea-Bissau 192777;Sierra Leone;Sierra Leone 192778;Guinea;Guinea 192779;Côte d'Ivoire;Côte d'Ivoire 192780;Liberia;Liberia 192781;Ghana;Ghana 192782;Togo;Togo 192783;Burkina Faso;Burkina Faso 192784;Benin;Benin 192785;Mali;Mali 192786;Niger;Niger 192787;Nigeria;Nigera 192788;Chad;Chad 192789;Sudan;Sudan 192790;Central African Republic;Central African Republic 192791;Guinea Ecuatorial;Equatorial Guinea 192793;Gabon;Gabon 192794;Congo (Brazzaville);Congo (Brazzaville) 192795;DR Congo;DR Congo 192796;Uganda;Uganda 192797;Elemi Triangle; 192798;Kenya;Kenya 192799;Somalia;Somalia 192800;Ethiopia;Ethiopia 192801;Djibouti;Djibouti 192830;Cameroon;Cameroon 195266;Namibia;Namibia 195267;Angola;Angola 195269;Burundi;Burundi
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, Stephan Knauss wrote: Die offenen Wege: select distinct (osm_id*-1) as id, name, name:en as name_en from planet_osm_line where osm_id 0 AND admin_level='2' osm2pgsql importiert auch geschlossene Grenzen zusaetzlich in die planet_osm_line. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Frederik Ramm wrote: Stephan Knauss wrote: select distinct (osm_id*-1) as id, name, name:en as name_en from planet_osm_line where osm_id 0 AND admin_level='2' osm2pgsql importiert auch geschlossene Grenzen zusaetzlich in die planet_osm_line. Du hast recht, sind da tatsächlich mit drin. Ist es eigentlich normal, dass da einige IDs mehrfach auftauchen? Oder hat es bei mir im Laufe der Zeit mal den Import zerbröselt? Die DB bekommt schon länger nur die Tages-Diffs. Ich will keinen Neu-Import. Habe immer noch den Task offen, dass ich suchen will warum die DB hier so zäh ist :( Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Hallo, Stephan Knauss wrote: Ist es eigentlich normal, dass da einige IDs mehrfach auftauchen? Oder hat es bei mir im Laufe der Zeit mal den Import zerbröselt? Die DB bekommt schon länger nur die Tages-Diffs. Eine Datenbank, die regelmaessig nur mit diffs gefuettert wird - Ausnahme die minute-replicate-Diffs - wird langsam inkonsistent, weil prinzipbedingt ein ganz kleiner Teil von Edits verloren gehen *kann* bei so einem Diff (auch Stunden- oder Tagesdiffs). - Das mit den mehrfachen IDs ist aber glaub ich darin begruendet, wie osm2pgsql diese Grenzpolygone bearbeitet (naemlich irgendwie komisch). Ich will keinen Neu-Import. Habe immer noch den Task offen, dass ich suchen will warum die DB hier so zäh ist :( Wenn Du halbwegs fit bist mit C/C++ oder einer anderen Sprache, mit der ein effizienter Datenbankzugriff moeglich ist, dann waere es eine Super-Sache, wenn Du mal ein Utility schriebst, mit dem man ein heruntergeladenes Planetfile mit der osm2pgsql-Datenbank abgleichen kann. Das wuerde es naemlich ermoeglichen, mit einem vermutlich kleineren Aufwand als komplettem Neuimport eine mit der Zeit etwas aus dem Ruder gelaufene Datenbank zu re-synchronisieren. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste aller Grenzrelationen der Staaten
Frederik Ramm wrote: Wenn Du halbwegs fit bist mit C/C++ oder einer anderen Sprache, mit der ein effizienter Datenbankzugriff moeglich ist, dann waere es eine Super-Sache, wenn Du mal ein Utility schriebst, mit dem man ein heruntergeladenes Planetfile mit der osm2pgsql-Datenbank abgleichen kann. Das wuerde es naemlich ermoeglichen, mit einem vermutlich kleineren Aufwand als komplettem Neuimport eine mit der Zeit etwas aus dem Ruder gelaufene Datenbank zu re-synchronisieren. Wo würdest du denn speziell ansetzen um signifikant Zeit gegenüber einem Neuimport zu sparen? Um alle Änderungen erkennen zu können müsstest du doch jeden Datensatz zumindest lesen. Ist da wirklich noch Zeitgewinn gegenüber einem Import? Ich hatte mal mit imports für einzelne Länder gespielt. Da war neu einlesen schneller als Diff einspielen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Ulf Lamping ulf.lamp...@googlemail.com wrote: Problem: Der Server hat einfach gut damit zu tun, die Daten passend zusammenzusammeln und auszuliefern. Du bist ja nicht alleine bei OSM, da sind ja auch noch andere am werkeln. Dadurch das wir auf den Daten *editieren*, kann man die Last auch nicht so einfach auf mehrere Server verteilen, wie es Nokia vielleicht tut. Die bei Nokia ändern Ihre Daten vielleicht einmal im halben Jahr, wir ändern andauernd. Frederik Ramm frede...@remote.org wrote: Haben andre ja schon geschrieben: Engpass ist hier die Datenbank. In der normalen Datenbank auf dem Server liegen die Daten kreuz und quer, aber es gibt natuerlich Datenbank-Indizes, die raeumlich beieinanderliegendes auch zusammensortieren. In einer zum Rendern aufbereiteten Datenbank (wie z.B. fuer Mapnik) ist das sogar noch deutlicher, da dort auch die Ways schon geometrisch sortiert sind (normal nur die Nodes). Es gibt aber auch Datenbanken, die fuer spezielle Zwecke optimiert sind, so wie z.B. ROMA und TRAPI. Zumindest bei TRAPI liegen die OSM-Dateien fuer bestimmte Gebiete tatsaechlich als einzelne Files auf der Platte. Ich nehme mal an, dass die Original Datenbank diejenige auf dem Server der Foundation ist, für den wir kürzlich gespendet haben. http://wiki.openstreetmap.org/wiki/Servers/smaug Laut Wiki hat die TRAPI Datenbank eine Verzögerung von 10 Minuten. Wenn ich es recht verstehe, könnte sie also für Zwecke wie wir Sie hier besprechen - nämlich Live Editierplugins direkt in der Karte - nicht dienlich sein. Denn man müsste die Auswirkung des Editierens ja umgehend sehen können. Demnach müsste dieses immer auf der unsortierten Kreuz und Quer Datenbank ausgeführt werden. Und demnach liegt dann hier der Casus knacktus, denn die ist eben langsam. Und das ist auch der Grund dafür, dass wir in JOSM mit runtergeladenen Daten statt live arbeiten und die Änderungen nur als rudimentäre Striche, statt beispielsweise in Mapnik Darstellung erscheinen. Ergo konnte der Flaschenhals, dem durch die damalige Spendenaktion für den Server der Foundation begegnet werden sollte, nicht beseitigt werden. Und er könnte nur dadurch beseitigt werden, dass der Original Server noch schneller würde, als der neue, weil hier die Änderungen auflaufen. Es ist kaum möglich, durch verteilte Server dem Problem der zu langsamen Auslieferung der Daten beim Live Editieren beizukommen. Also bringt der Strato Server hier auch keine Abhilfe. Sehe ich dies alles so richtig? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strato sponsort 3 Server für OSM
Tirkon schrieb: Laut Wiki hat die TRAPI Datenbank eine Verzögerung von 10 Minuten. Wenn ich es recht verstehe, könnte sie also für Zwecke wie wir Sie hier besprechen - nämlich Live Editierplugins direkt in der Karte - nicht dienlich sein. Korrekt Denn man müsste die Auswirkung des Editierens ja umgehend sehen können. Demnach müsste dieses immer auf der unsortierten Kreuz und Quer Datenbank ausgeführt werden. Und demnach liegt dann hier der Casus knacktus, denn die ist eben langsam. Nein, die ist sogar inzwischen ziemlich schnell. Kommt halt auf die Sichtweise an was schnell ist. Und das ist auch der Grund dafür, dass wir in JOSM mit runtergeladenen Daten statt live arbeiten Nein, hat damit nichts zu tun. und die Änderungen nur als rudimentäre Striche, statt beispielsweise in Mapnik Darstellung erscheinen. Nein, hat damit nichts zu tun. Ergo konnte der Flaschenhals, dem durch die damalige Spendenaktion für den Server der Foundation begegnet werden sollte, nicht beseitigt werden. Kommt auf die Sichtweise an. Den Flaschenhals endgültig beseitigen kannst du prinzipiell nicht, wenn die Anzahl der Clients und die Datenmenge kontinuierlich wächst. Das ist dann so ähnlich wie eine DDOS. Und er könnte nur dadurch beseitigt werden, dass der Original Server noch schneller würde, als der neue, weil hier die Änderungen auflaufen. Es ist kaum möglich, durch verteilte Server dem Problem der zu langsamen Auslieferung der Daten beim Live Editieren beizukommen. Also bringt der Strato Server hier auch keine Abhilfe. Korrekt. Sehe ich dies alles so richtig? Teilweise. Gruß, ULFL P.S: Wieso fragst du eigentlich? Dir ist schon bewußt, daß du andere von der Arbeit abhälst? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC-Import startet und braucht eure Hilfe
On 2009-10-11, Frank Sautter openstreet...@sautter.com wrote: Marcus Wolschon schrieb: Die Areas sind am einfachsten und deshalb fangen wir mit denen an um für die anderen Erfahrungen zu sammeln. die regierungsbezierke und landkreise in baden-württemberg sind seit gestern abend komplett... Super. :) aber das ganze ist enorm zeitraubend! da muss eine andere lösung her! insgesamt muss das mehr (halb-)automatisiert werden sonst sinkt das engagement der leute schnell auf ein sehr niedriges maß. Wenn du konkrete vorschläge hast kann ich die gerne umsetzen. Ich habe einige Monate versucht da allgemeingültige Regeln zu finden und alles hat mehr Arbeit in der Beseitigung und dem Finden von Fehlern verursacht als es Zeit gespaart hat. es fehlt auch eine vernünftige suchmöglichkeit nach den tmc-entities. die aufteilung in zig seiten im wiki ist eine katastrophe. Die Aufteilung ist aufgrund von Begrenzungen des Wikis notwendig. sinnvoll wäre eine dedizierte webanwendung mit datenbank und anbindung an die minütlichen diffs vom planetfile. so könnten dann auch gleich plausibilitätschecks durchgeführt werden und die bereits getaggten gebiete entsprechend markiert werden. ich habe mit den DONE meldungen im wiki mehr zeit verbracht als mit dem eintragen mit josm... das ist doof. Kannst du gerne schreiben. Hast du einen Server der ein minütlich aktuelles Planetfile in einer für sowas nutzbaren Datenbank hostet? Plausi-Checks kann ich dir machen aber die Webanwendung wirst du selbst schreiben müssen. Wäre aber bestimmt auch für andere, spätere Imports sinnvoll. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
