Haas, Janina | 2 Dec 13:01 2015
Picon

Korrektur der Koordinaten fuer PLZ 10409, Berlin, Deutschland

Hallo,

ich bitte um Korrektur der aktuell hinterlegten Koordinaten: 52.517/13.4 fuer PLZ 10409, Berlin,
Deutschland in die korrekten Koordinaten von Berlin, Prenzlauer Berg: 52.543961/13.440592.
Es liegen etwa 4km zwischen den Koordinaten.

Mit freundlichen Gruessen
Janina Haas

--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb <at> phpbar.de
Informationen: http://opengeodb.de
Mit freundlicher Untersttztung von php::bar (http://phpbar.de)
Frank Meineke | 30 Oct 15:21 2015
Picon

Korrektur in AGS Eintr├Ągen

Hallo,

vielen Dank für die großartige und eben freie Liste. Ich interessiere mich insbesondere für die AGS und PLZ Einträge.

 

Ich sah allerdings folgendes Problem: Zahlreiche Gemeinden haben, nach verschiedenen Gebietsreformen im Osten, einen mittlerweile ungültigen AGS Eintrag. Mir sind es jetzt zuviele um sie mit dem Web-Frontend zu ändern – tatsächlich geht es um über 1080 Einträge; z.B.

15404    13053016             DALKENDORF

ist jetzt

15404    13072024          DALKENDORF

 

Betroffen sind Gemeinden mit folgenden AGS Präfixen:

(Evtl. sind dabei auch Alt-Kreise in mehrere Neu-Kreise aufgegangen – das habe ich nicht recherchiert)

                Gemeinden mit AGS-Präfix 13001* gehören nun zu Kreis  13075

                Gemeinden mit AGS-Präfix 13002* gehören nun zu Kreis  13071

                Gemeinden mit AGS-Präfix 13006* gehören nun zu Kreis  13074

                Gemeinden mit AGS-Präfix 13053* gehören nun zu Kreis  13072

                Gemeinden mit AGS-Präfix 13060* gehören nun zu Kreis  13076

                Gemeinden mit AGS-Präfix 13061* gehören nun zu Kreis  13073

                Gemeinden mit AGS-Präfix 14171* gehören nun zu Kreis  14521

                Gemeinden mit AGS-Präfix 14177* gehören nun zu Kreis  14522

                Gemeinden mit AGS-Präfix 14178* gehören nun zu Kreis  14523

                Gemeinden mit AGS-Präfix 14193* gehören nun zu Kreis  14524

                Gemeinden mit AGS-Präfix 14272* gehören nun zu Kreis  14625

                Gemeinden mit AGS-Präfix 14280* gehören nun zu Kreis  14627

                Gemeinden mit AGS-Präfix 14286* gehören nun zu Kreis  14626

                Gemeinden mit AGS-Präfix 14287* gehören nun zu Kreis  14628

                Gemeinden mit AGS-Präfix 14379* gehören nun zu Kreis  14729

                Gemeinden mit AGS-Präfix 14389* gehören nun zu Kreis  14730

                Gemeinden mit AGS-Präfix 15171* gehören nun zu Kreis  15091

 

Für mich korrigiere ich das beim Einlesen – mich interessieren nur die Kreise; tatsächlich wäre aber jede Gemeinde zu ändern, da sich auch die letzten Ziffern ändern.

Sehe ich das falsch? Wie kann man das systematisch angehen?

 

Gruß, Frank Meineke

--

Dr. Frank Meineke

Universitätsmedizin Leipzig

 

 

 

 

 

 

--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb <at> phpbar.de
Informationen: http://opengeodb.de
Mit freundlicher UnterstŘtztung von php::bar (http://phpbar.de)
Michael Melster | 12 Jan 07:58 2015
Picon

SQL Alle Bundesl├Ąnder, Landkreise und St├Ądte

Hallo,

ich versuche seit 2 Tagen eine SQL Abfrage zu erstellen, um eine Liste 
aller St├Ądte mit Namen, PLZ, Lat/Long, Landkreis und Bundesland zu 
erhalten. Leider bisher ohne Erfolg.

Es gibt zwar das Beipiel f├╝r Landkreise in DE unter 
http://opengeodb.org/wiki/Beispiele oder aller St├Ądte unter 
http://opengeodb.org/wiki/OpenGeoDB_-_Umkreissuche

Hier ist mir aber nicht wirklich klar, wie ich dort die fehlenden Daten 
hinzu bekommen.

H├Ątte jemand eine z├╝ndende Idee f├╝r mich?

Gr├╝├če
Micha

P.S.
Nebenbei liefert das SQL Beispiel f├╝r Landkreise 
(http://opengeodb.org/wiki/Beispiele) nicht nur die Daten aus DE sondern 
aus allen Staaten.

--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb <at> phpbar.de
Informationen: http://opengeodb.de
Mit freundlicher Untersttztung von php::bar (http://phpbar.de)
Florian Lohoff | 29 Nov 10:44 2014
Picon

loc 17676 erg├Ąnzen um PLZ 33311


Hi,

aufgrund der OSM Daten bin ich darauf gestossen das f├╝r den OpenGeoDB
Eintrag f├╝r G├╝tersloh (Stadt) die PLZ 33311 fehlt.

Selber eintragen scheine ich es nicht zu k├Ânnen.

Insgesamt schweigt sich http://opengeodb.org ziemlich aus wo Erg├Ąnzungen,
Änderungen, Fehler landen sollen.

Flo
-- 
Florian Lohoff                                                 f <at> zz.de
--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb <at> phpbar.de
Informationen: http://opengeodb.de
Mit freundlicher UnterstŘtztung von php::bar (http://phpbar.de)
Ilya Khanataev | 18 May 23:15 2014

Welcher Datentyp entspricht der Stadt "im herk├Âmmlichen Sinne"?

Hallo!

Wenn ich mir die Liste der OpenGeoDB Location-Typen anschaue, vermisse den Typ "Stadt". Das hat wohl damit zu tun, dass bei OpenGeoDB die Daten GIS-technisch deffirenzierter gespeichert sind.

Doch für mich als Laien: Welcher Location-Typ entspricht am ehesten der Stadt in dem Sinne, in dem das üblicherweise gemeint wird, wenn jemand z.B. Sachen wie "das Wetter in Köln", "Pizza-Lieferung in Hamburg" oder "alle Hochschulen in Berlin" bei der Suchmaschiene anfragt?

Ist es "Landkreis" (100500000), "Politische Gliederung" (100600000) oder "Ortschaft" (100700000)?

Technisch gesprochen, was wäre in diesem SQL-Statement

SELECT
    *
FROM
    geodb_textdata
JOIN
    geodb_locations ON geodb_textdata.loc_id = geodb_locations.loc_id
WHERE
    loc_type = LOCATION_TYPE_ID
;

die richtige `LOCATION_TYPE_ID`, wenn man die Namen aller Städte (i.S. wie oben beschrieben) bekommen möchte?
--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb <at> phpbar.de
Informationen: http://opengeodb.de
Mit freundlicher UnterstŘtztung von php::bar (http://phpbar.de)
AuFinNS | 24 Jan 07:29 2013
Picon

Fehler in DE.tab vom 17.01.2013

Hallo, 

die o.g. Datei ist aktuell nur bedingt brauchbar. Die Zeilen 60673/4 haben folgenden Inhalt:

151845 TEST test 34 6543 test 34622 04543 324235 te test 8 16918 1
151847 Änderungen vornehmen kann ICH BITTE UM ENTSCHULDIGUNG ich bitte um Entschuldigung ich bin überrascht. dass ein nicht-angemeldeter User bemerkt, bzw. die Änderungen Ich bitte nochmals um Entschuldigung routinemässig qualitätsgesichert ich hoffe, dass dies jemand 9 151845 1

In der Hoffnung, dass das jemand zeitnah korrigieren kann :)

Max

--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterst├╝tztung von php::bar (http://phpbar.de)
Martin Trautmann | 4 Dec 10:30 2012
Picon
Picon

Re: Inkonsistenzen

On 12-12-04 10:24, Anja Wilmer wrote:
> Wollen Sie mich eigtlich verarschen?

Wenn Sie das w├╝nschen? Wie kann ich das f├╝r Sie tun?

Gru├č
Martin
--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterst├╝tztung von php::bar (http://phpbar.de)

Julia Ilnseher | 29 Nov 16:08 2012
Picon

Inkonsistenzen

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

-- 
Julia Ilnseher | Softwareentwicklerin

markt.de GmbH & Co. KG
Nymphenburger Stra├če 14
80335 M├╝nchen
Tel: +49 89 878068 123
Fax: +49 89 878068 199

Gesch├Ąftsf├╝hrer: Sang-Woo Pai
Sitz: M├╝nchen
Amtsgericht: M├╝nchen HRA 86724

--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterst├╝tztung von php::bar (http://phpbar.de)

Tomi Engel | 2 Nov 00:18 2012

Nord- und Ostsee?

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 

	<http://de.wikipedia.org/wiki/Ausschlie├čliche_Wirtschaftszone>

und dann als Untertyp "Nordsee" und die "Ostsee".

In der Mailingliste konnte ich dazu noch keine Debatte finden.

Aloha
	Tomi
--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterst├╝tztung von php::bar (http://phpbar.de)

Tomi Engel | 2 Nov 00:13 2012

"Haldensleben" doppelt

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

--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterst├╝tztung von php::bar (http://phpbar.de)

Sarah Maniecki | 31 Oct 21:33 2012
Picon

Re: Neue PLZ Wittenberg PLZ.tab

Guten Abend und hallo Martin, 

ich habe noch mal eine Verst├Ąndnisfrage zu der erw├Ąhnten PLZ.tab:

Ich verwende grunds├Ątzlich f├╝r ein Projekt die Tabellen aus der DE.sql.
Regelm├Ą├čig aktualisiere ich die Daten mit Hilfe der changes.sql

Bisher hat auch alles wunderbar funktioniert.
Ich kann gerade nur die "PLZ.tab" nicht ganz richtig einordnen. 
Geh├Âren die Daten aus dieser Datei nicht auch in die Datenbank
'geodb_textdata'?

Und falls ja, woran scheitert es, dass Daten aus der PLZ.tab in die
change.sql ├╝bertragen werden bzw. 
kann man den Prozess beschleunigen, unterst├╝tzen?

Falls nein:
W├╝rde man dann eine simple Abfrage, ob PLZ und Ort ├╝bereinstimmen ├╝ber die
Daten aus der PLZ.tab abfragen,
anstatt ├╝ber die geodb_textdata-Tabelle?

Bisher habe ich alle Funktionalit├Ąten ohne die PLZ.tab (bis hier hin
erfolgreich) implementiert.

Vielen Dank im Voraus f├╝r eine Antwort.
Sch├Âne Gr├╝├če

Sarah

-----Urspr├╝ngliche Nachricht-----
Von: opengeodb-bounces@...
[mailto:opengeodb-bounces@...] Im
Auftrag von Martin Trautmann
Gesendet: Dienstag, 23. Oktober 2012 17:38
An: opengeodb@...
Betreff: Re: [opengeodb] Neue PLZ Wittenberg

On 12-10-23 16:15, Sarah Maniecki wrote:

> Wittenberg  hat nun die PLZ 06889.
> 
> Kann die Datenbank diesbez├╝glich aktualisiert werden?

Hallo Sarah,

danke, f├╝r die PLZ.tab habe ich's erg├Ąnzt. F├╝r Wittenberg oder die
entsprechenden Ortsteile kannst du's selbst erg├Ąnzen:
<http://fa-technik.adfc.de/code/opengeodb.pl?locid=20510;c=DE>
bzw. weiter ├╝ber
<http://fa-technik.adfc.de/code/opengeodb.pl?parts=20510;c=DE>

Sch├Ânen Gru├č
Martin
--
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterst├╝tztung von php::bar (http://phpbar.de)

--

-- 
Mailingliste OpenGeoDB
Listenadresse: opengeodb@...
Informationen: http://opengeodb.de
Mit freundlicher Unterst├╝tztung von php::bar (http://phpbar.de)


Gmane