http://blog.gmane.org/gmane.comp.gis.opengeodb hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.gis.opengeodb/5124 <pre>Hallo,  die o.g. Datei ist aktuell nur bedingt brauchbar. Die Zeilen 60673/4 haben folgenden Inhalt: 151845TESTtest346543test3462204543324235tetest8169181 151847Änderungen vornehmen kannICH BITTE UM ENTSCHULDIGUNGich bitte um Entschuldigungich bin überrascht. dassein nicht-angemeldeter Userbemerkt, bzw. die ÄnderungenIch bitte nochmals um Entschuldigungroutinemässig qualitätsgesichertich hoffe, dass dies jemand 91518451 In der Hoffnung, dass das jemand zeitnah korrigieren kann :) Max </pre> AuFinNS 2013-01-24T06:29:41 http://comments.gmane.org/gmane.comp.gis.opengeodb/5118 <pre>Hallo zusammen! Ich bin neu hier auf der Mailingliste :) Wie ihr an meiner Signatur sehen könnt, arbeite ich bei markt.de. Leider haben wir im Moment eine ziemlich veraltete Geo-Datenbank, und sind auf der Suche nach Möglichkeiten, wie wir sie kontinuierlich aktuell halten können, auf die OpenGeoDb gestoßen. Beim Versuch die DE.tab zu parsen und einen Objektbaum aufzubauen, habe ich ein paar Inkonsistenzen entdeckt und dachte mir, dass ich die am besten der Community mitteile. Schließlich ist das ein offenes Projekt, das davon lebt, dass Leute, die es benutzen, ihre Erkenntnisse auch wieder zurückgeben :) Also hier sind meine Verbesserungsvorschläge: - Der Datensatz mit der loc-id 23175 scheint irgendwie kaputt zu sein. Meiner Meinung nach wäre es wohl am besten, ihn komplett aus der Tabelle zu löschen. Eine Verbesserung wäre, zumindest "1" im Feld "invalid" einzutragen. - Das Feld "invalid" ist ein wenig inkonsistent befüllt. Offensichtlich scheint "leerer String" und "0" zu bedeuten, dass der Datensatz valide ist, "1" (und "null" bei Datensatz 23175), dass der Datensatz nicht valide ist. Stimmt das soweit? Allerdings gibt es Datensätze die aus der Reihe herausfallen: 153490, 153609 und 556 scheinen nicht valide zu sein, weil sie fast vollständig leer sind, allerdings steht im invalid-Feld für diese Datensätze "0" oder "". Sollten diese 3 Datensätze nicht eigentlich invalide sein, also "1" in dem Feld stehen? Es sollte auch in der Dokumentation ergänzt werden, dass in diesem Feld nicht nur 1 und 0 stehen kann. Weil wenn man einen boolean erwartet, ist man schon ein bisschen verwundert, wenn man plötzlich Felder mit leerem String sieht. - Das Feld loc_id sollte eigentlich eindeutig sein, es gibt aber zwei Städte, die die selbe ID 153671 haben (Maria Veen und Rhedebrügge, stehen in der DE.tab ganz unten). Das sollte auf jeden Fall schnell bereinigt werden. Ich weiß nicht, wie andere das machen, aber meine MySQL-DB hätte schon ganz gerne, dass der primary key auch eindeutig ist ;) - Im Feld "einwohner" gibt es ein paar Einträge, die enthalten einen Punkt, offensichtlich als Tausender-Trennzeichen. Im Feld "flaeche" gibt es auch Zahlen, die einen Punkt enthalten. Hier scheint es sich aber offensichtlich um ein Dezimalkomma zu handeln. Das ist meiner Meinung nach gefährlich, weil man das nicht erwartet und dann Fehler beim parsen macht. Auf die unterschiedliche Formattierung sollte man auf jeden Fall in der Doku hinweisen. Noch besser wäre, die Zahl mit deutschem locale zu formattieren, so dass ein Komma statt einem Punkt beim Feld "flaeche" verwendet wird. - Feld "level": Ich habe 2 Datensätze entdeckt, die ein komisches Level haben: Die Orte 18048 und 35793 befinden sich auf dem Level "0" . Das ist vermutlich falsch, da schon Deutschland auf Level 2 ist. - Das Feld "of" sollte wohl eigentlich bei jedem Datensatz gefüllt sein (da ja jedes Objekt einen parent hat) aber es gibt ein paar Datensätze, da steht nichts in diesem Feld: 285, 278, 275, 190, 189, 187, 144602, 144600, 113129, 113126 - Bei diesen Einträgen in das Feld "typ" scheint derjenige, der das eingetragen hat, nicht so genau gewusst zu haben, was in das Feld gehört: - 100900000 (locid 81786 und 84968) - 7 (locid 151792) - 8 (locid 151794 und 151796) So, ich hoffe ich kann damit ein bisschen dazu beitragen, dass die Datenbank qualitativ besser wird :) Viele Grüße Julia Ilnseher </pre> Julia Ilnseher 2012-11-29T15:08:15 http://comments.gmane.org/gmane.comp.gis.opengeodb/5111 <pre>Hallo, für die Verrottung von ein paar Offshore-Windrädern bräuchte ich auf die Nord- und Ostsee im Datenbestand. Wie sollte man das Modellieren? Im Prinzip bräuchte ich da die &lt;http://de.wikipedia.org/wiki/Ausschließliche_Wirtschaftszone&gt; und dann als Untertyp "Nordsee" und die "Ostsee". In der Mailingliste konnte ich dazu noch keine Debatte finden. Aloha Tomi </pre> Tomi Engel 2012-11-01T23:18:29 http://comments.gmane.org/gmane.comp.gis.opengeodb/5110 <pre>Hallo allerseits, der Ort "Haldensleben" ist offenbar doppelt. ID: 556 und 17808 die 556 hat zwar keinen Namen mehr (also über das Web UI nicht "suchbar"), aber noch Ortsteile, die im 17808 Eintrag fehlen? Soll ich die Ortsteile einfach auf die neue ID umbiegen … oder wurden die Ortsteile aus einem anderen Grund "abgehängt". Aloha Tomi PS: Es gibt auch noch andere IDs die "leere" Zeile generieren … wie kann ich die bereinigen? DE;153490;20249;7;;;;;;;;;;;RP;;0 DE;153609;22201;7;;;;;;;;;;;;;0 ;151805; 153369 152769 150623 152986 152988 152480 80062 23175 </pre> Tomi Engel 2012-11-01T23:13:31 http://comments.gmane.org/gmane.comp.gis.opengeodb/5106 <pre>Hi, im Rahmen eines aktuellen Projektes habe ich mich mit opengeodb beschäftigt. Dabei habe ich mir ein kleines Script gebastelt, welches die opengeodb automatisch auf linux Systemen "installieren" kann. https://gist.github.com/3941528 Feedback und Verbesserungsvorschläge sind gerne willkommen! Grüße Andi PS: Ich habe auch einen Forumseintrag dazu gemacht: https://sourceforge.net/projects/opengeodb/forums/forum/449280/topic/6058475 </pre> Andreas Voss 2012-10-24T08:09:10 http://comments.gmane.org/gmane.comp.gis.opengeodb/5101 <pre>Hallo zusammen, da ich nicht ganz verstanden haben, wie und ob man neue Datensätze einpflegen kann, wollte ich Folgendes an die Gemeinschaft weitergeben: In Wittenberg wurden die PLZ neu verteilt. Wittenberg hat nun die PLZ 06889. Kann die Datenbank diesbezüglich aktualisiert werden? Werden noch weitere Informationen benötigt? Viele Grüßen und Danke im Voraus, Sarah Maniecki ------------------------- </pre> Sarah Maniecki 2012-10-23T14:15:00 http://comments.gmane.org/gmane.comp.gis.opengeodb/5100 <pre>Hallo, mir ist ein Schreibfehler eines Ortsnamens in der PLZ-Tabelle (PLZ.tab) aufgefallen, die unter diesem Link zum Download angeboten wird: http://fa-technik.adfc.de/code/opengeodb/PLZ.tab Der Eintrag für die PLZ "92699" lautet: 120299269912.219986081847149.6373355783739Bechtsried Der Ort wird dort fälschlicherweise "Bechtsried" geschrieben - korrekt wäre "Bechtsrieth". Könnte dies ausgebessert werden? Der Fehler ist nur in der PLZ.tab enthalten; die andere Datenbank "DE.tab" enthält die korrekte Schreibweise. Danke! Viele Grüße, Konstantin Preißer </pre> Konstantin Preißer 2012-08-05T20:27:31 http://comments.gmane.org/gmane.comp.gis.opengeodb/5097 <pre>Hallo zusammen, Ich benutze OpenGeoDB, um bei eingehenden Anrufen zusätzlich zur Nummber auch den Ort des Anrufes anzuzeigen. Nun gibt es einige Vorwahlen, die von mehreren Orten belegt sind - zum Beispiel 089 München, Typ: Landeshauptstadt, Ebene 6 089 Oberschleißheim, Typ: Gemeinde, Ebene 6 Da mir München aber mehr sagt als Oberschleißheim würde ich gern München anzeigen. Wie ist das technisch möglich? Die Ebene ist gleich, also bleibt meines Erachtens nach nur der Typ übrig - aber der ist textuell und ungeordnet. Gibt es hier eine Möglichkeit, die Rangordnung der Typen zu unterscheiden? Oder gibt es eine andere Möglichkeit, München vor Oberschleißheim zu bevorzugen? (Manuelles Löschen der unerwünschten Daten ist nicht so einfach, da über 2200 Vorwahlen von mehreren Orten belegt sind.) </pre> Christian Weiske 2012-08-05T12:23:20 http://comments.gmane.org/gmane.comp.gis.opengeodb/5096 <pre>Hallo! Die Beispiel- und Minimalimplementierung für die Umkreissuche und Entfernungsberechnung "ogdbDistance" ist nun eine neue Version zum Download verfügbar: http://hoppe-media.de/dl/ogdbDistance.zip Danke an Benjamin Leist für den Hinweis. Gruß, Manuel </pre> Manuel Hoppe 2012-07-28T14:02:04 http://comments.gmane.org/gmane.comp.gis.opengeodb/5095 <pre> Guten Tag, vielen Dank für Ihre Nachricht. Ich bin am 30. Januar wieder im Büro und werde mich dann umgehend bei Ihnen melden. Ihr Anliegen lässt sich nicht aufschieben? Dann wenden Sie sich bitte an unsere Zentrale unter +49.35165554-0, dort hilft man Ihnen gerne weiter. Mit freundlichen Grüßen Stephan Köhler _________________________________ www Deutscher Tele Markt GmbH Internet- und Werbeagentur Maxstraße 6 im Art'otel 01067 Dresden Telefon 0351 6 555 4 - 0 Telefax 0351 6 555 4 - 22 Web www.deutscher-tele-markt.de Finanzamt Dresden I Steuernummer: 201/122/03703 Amtsgericht Dresden: HRB 17198 Geschäftsführer: Mark Eckert _________________________________ </pre> stephan.koehler-hK+kUa6WXws< at >public.gmane.org 2012-01-23T20:10:08 http://comments.gmane.org/gmane.comp.gis.opengeodb/5094 <pre>Hallo, hat jemand http://www.data.gouv.fr/ schon genauer untersucht oder kennt andere brauchbare Quellen, um die opengeodb um Frankreich zu erweitern? siehe auch &lt;http://www.heise.de/newsticker/meldung/Frankreich-Open-Data-Portal-startet-1419820.html&gt; Schönen Gruß Martin </pre> Martin Trautmann 2012-01-23T20:01:36 http://comments.gmane.org/gmane.comp.gis.opengeodb/5077 <pre>Da hier es hier auf der Mailingliste noch niemand erwähnt hat: http://opengeodb.giswiki.org/wiki und damit auch auf opengeodb.de: MfG Andi </pre> Andreas Hubel 2011-12-03T14:19:56 http://comments.gmane.org/gmane.comp.gis.opengeodb/5073 <pre>Hallo! Es gibt eine neue Version der ogdbDistance: http://www.hoppe-media.net/dl/ogdbDistance.zip Neben einem kleinen Code-Facelift kann nun auch in den internationalen Daten (z.B. AT.tab) gesucht werden. Neu dazu gekommen ist die Umkreissuche. Die Libary soll eine einfache Benutzung der Datenbestände möglich machen. Genutzt werden die jeweiligen *.tab-Dateien. Mit den vorhandenen Funktionen ist jeder PHP-Benutzer in der Lage Entfernungs- und Umkreis-Features in die eigenen Programme einzubauen. Viel Spass damit, Manuel </pre> Manuel Hoppe 2011-10-13T22:14:26 http://comments.gmane.org/gmane.comp.gis.opengeodb/5044 <pre> Hallo, mal eine kleine Anregung. Wie wäre es die Datenbestände mal besser zu Pflegen? Eine Umstellung aller Datenbestände auf UTF-8 wäre eine Klasse Idee. Die "changes.sql" beinhaltet zwei verschiedene Codierungen. Irgendwie scheint mir hier keiner mehr so richtig Lust auf OpenGeoDB zu haben. Keine aktuellen SQL dumps. Nur eine Changes SQL, welche man nicht verwenden kann. Schade eigentlich um das Projekt. Würde sich mal ein Profi, was Datenbanken anbelangt der Sache annehmen. Bitte ;-) Und das mit dem dusseligen TAB's lassen! MfG Oliver K. -- Mailingliste OpenGeoDB Listenadresse: opengeodb-r1mDYR0DdAyzQB+pC5nmwQ&lt; at &gt;public.gmane.org Informationen: http://opengeodb.de Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)</pre> O K 2011-08-15T11:04:02 http://comments.gmane.org/gmane.comp.gis.opengeodb/5036 <pre>Wo wir gerade beim Ausmisten sind: Die Domain opengeodb.de läuft noch bei mir. Irgendwelche Vorschläge oder gar Freiwillige, die sich der Domain dauerhaft annehmen möchten? Ansonsten werde ich die Domain auch gerne als Weiterleitung weiterführen. Viele Grüße Arne </pre> Arne Klempert 2011-05-30T10:31:43 http://comments.gmane.org/gmane.comp.gis.opengeodb/5030 <pre>Hi Wir nutzen in einem Projekt bei dem ich hinzu gestoßen bin die GeoClass for PHP. Die Version die es davon auf http://sourceforge.net/projects/geoclassphp/ gibt ist allerdings etwas älter und der letzte Commit am Code auch schon 7 Jahre her. Da sie aber noch regelmäßig herunter geladen wird und auch immernoch bei euch verlinkt ( http://opengeodb.giswiki.org/wiki/OpenGeoDB ) ist, gehe ich mal davon aus, dass sie zumindest weiter genutzt wird, aber aufgrund der wohl inaktiven Maintainer keine Patches mehr in diesen Teil des Projektes fließen. Da wir auch ein paar kleinere Patches haben, wollte ich nun fragen, wie hier die Einstellung dazu wäre, wenn ich den Code zu Github migriere. Mit freundlichem Gruß Daniel Fahlke </pre> Daniel Fahlke 2011-05-23T22:35:36 http://comments.gmane.org/gmane.comp.gis.opengeodb/5027 <pre>Tach zusammen :) Ich habe mich das erste Mal mit der OpenGeoDB beschäftigt... Klappt auch alles super. Ich habe sogar die Drecks Entfernungsberechnung geknackt bekommen. Jetzt nur eine kleine Frage... Ich bekomme die Results nicht nach der Entfernung (ASC) Sortiert. Mir fehlts wohl irgendwo an Daten... Kann mir jemand helfen ? DAS HIER: $Ergebnis = $Suche-&gt;Suche($PLZ, $Umkreis, array('name', 'street', 'PLZ', 'location', 'country', 'telefon', 'telefax', 'url', 'email', 'Latitude', 'Longitude'), 'name', 'ASC'); Hätte ich gerne mit der Variable für die Entfernung, die sich so ungefähr bildet: // Geodaten Ort1 - Aus der GeoDB $B1 = $Eintrag-&gt;Latitude; $L1 = $Eintrag-&gt;Longitude; // Geodaten Ort2 - Erstellt aus dem INPUT Feld PLZ und INNER JOIN suche nach PLZ &amp; Lat und Long $B2 = $lat[0]; $L2 = $lat[1]; // Kreiszahl Pi $pi = pi(); $breite1 = $B1 / 180 * $pi ; $länge1 = $L1 / 180 * $pi ; $breite2 = $B2 / 180 * $pi ; $länge2 = $L2 / 180 * $pi ; $e = acos( sin($breite1)*sin($breite2) + cos($breite1)*cos($breite2)*cos($länge2-$länge1) ); $entfernung = $e * 6378.137; Wie kann ich nun dem Script klar machen, dass er für die Sortierung $entfernung nehmen soll ? Schon mal jemand gemacht ? Wer mehr infos braucht, ruhig melden… Vielen Dank im Voraus… Stefan Schmidt </pre> Stefan Schmidt | Magma:Solutions 2011-05-17T16:02:28 http://comments.gmane.org/gmane.comp.gis.opengeodb/5023 <pre>Hallo Wir fahren im Prinzip nicht schlecht mit dem Import des grossen SQL-Dumps, aber es wird doch eher selten einer erstellt. Zudem dauert das Einlesen doch recht lange und 99% der Daten sind ja gar nicht aktueller geworden. Hat schon jemand eine Lösung gebaut, mit der man die .TAB-Files, die ja aktueller und kleiner sind, schnell und einigermassen schmerzfrei einlesen kann - und wäre bereit, das Wissen zu teilen? Im Wiki sind ja im Prinzip genügend Infos, um selbst etwas zu bauen. Aber der Leidensdruck ist noch nicht ganz hoch genug. Inkrementelle Dumps mit Update-Statements gibt's ja vermutlich nicht? Wäre ja auch etwas aufwändig zu generieren. Peter Guhl </pre> web-it-hIKb5/UCZ3kfv37vnLkPlQ< at >public.gmane.org 2011-05-16T06:52:31 http://comments.gmane.org/gmane.comp.gis.opengeodb/5019 <pre>Guten Tag! Hat sich bereits jemand die Mühe gemacht, aus den GEO Daten nur PLZ plus Ortsname herauszulesen? Ich wäre sehr dankbar, wenn mir jemand eine solche Liste zur Verfügung stellen würden. Mit freundlichen Grüßen Ronald Kasper </pre> Ronald Kasper 2011-04-15T08:29:49 http://comments.gmane.org/gmane.comp.gis.opengeodb/5016 <pre>Hallo Gemeinde! Nachdem das Einlesen des myql-dumps (opengeodb.sql) viel zu lange (mehrere Stunden lang!) dauerte, die vom mysqld verursachte CPU-Last aber 1 bis 3 Prozent dümpelte - aber das Geratter der Festplatte Angst machte, habe ich mir das mal näher angeschaut: Das Problem resultiert daraus, dass bei mir autocommit auf 1 steht. Das ist z.B. die Standardvorgabe bei SuSE-Linux... Dies führte zu ewig dauernden Inserts. Dann stand noch ein COMMIT zu viel, und zwar vor dem Begin der Inserts. Mit folgenden Änderungen geht es sehr viel schneller: Ab Zeile 1: /* * MySQL */ /* Erst noch testen: SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO"; */ SET FOREIGN_KEY_CHECKS=0; SET AUTOCOMMIT=0; SET NAMES 'utf8'; BEGIN; /* * Table structure for table 'geodb_type_names' */ .... und natürlich am Ende: SET FOREIGN_KEY_CHECKS=1; COMMIT; Grüße Jörg Reinholz http://fastix.org </pre> Jörg Reinholz 2011-01-08T17:27:31 http://comments.gmane.org/gmane.comp.gis.opengeodb/5014 <pre>Hallo, nach welcher Konvention werden die Ortsnamen eingetragen (text_type: 50010000)? Mal finden sich irgendwelche Zusätze (Fluss, Gebietsname, "Universitätsstadt") hinter dem Ortsnamen, bei anderen dann aber wieder nicht. Einige Beispiele für Ortsnamen mit Zusätzen: loc_id text_typetext_val 13810 500100000 Augsburg, Bayern 16348 500100000 Essen, Ruhr 20556 500100000 Mainz am Rhein 20600 500100000 Mannheim, Universitätsstadt 24079 500100000 Schwerin, Mecklenburg ... Ein bestimmtes System kann ich dahinter nicht erkennen, die Vergabe erscheint mir auch nicht konsistent (sofern es sich nicht um amtliche Namenszusätze handelt). Ich würde es für sehr hilfreich halten, wenn zumindest in einem extra Feld die offizielle Ortsbezeichnung (ohne nicht-amtliche Zusätze) aufgenommen werden könnte. Viele Grüße Alexander </pre> Alexander Winkler 2010-12-27T14:30:13 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.gis.opengeodb