|

»

Php German - opengeodb

textdata vs. intdata

View: New views

3 Messages — Rating Filter: Alert me

	textdata vs. intdata by Peter Wendorff :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Obwohl ich die Frage sicherlich schon früher gestellt habe - jedenfalls meine ich mich daran erinnern zu können: Gibt es einen Grund, warum diverse int-Typen in geodb_textdata liegen? Allen Voran Verknüpfungen zu anderen Entities per loc_id. Insbesondere also: 400100000 Teil von 400200000 Ebene 600700000 Einwohnerzahl 600800000 Höhenangabe in Metern 610000000 Fläche in km² 650700001 Ungefähre Einwohnerzahl 650800001 Maximale Höhe 650800002 Minimale Höhe 650800003 durchschnittliche Höhe 650800004 Höhe am Referenzpunkt 650800005 Höhe an der angegebenen Koordinate Diese gehören sämtlich in den Bereich geodb_intdata. Ich weiß, dass das erstmal für Inkompatiblitäten sorgen wird, aber mein Vorschlag wäre dennoch, dies demnächst zu ändern und die entsprechenden Datensätze zu verschieben. Gruß Peter -- Mailingliste OpenGeoDB Listenadresse: opengeodb@... Informationen: http://opengeodb.de Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
	Re: textdata vs. intdata by Martin Trautmann :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message > Obwohl ich die Frage sicherlich schon früher gestellt habe - jedenfalls > meine ich mich daran erinnern zu können: > > Gibt es einen Grund, warum diverse int-Typen in geodb_textdata liegen? > Allen Voran Verknüpfungen zu anderen Entities per loc_id. > Insbesondere also: > 400100000 Teil von > 400200000 Ebene Ich glaube, die Frage hatten wir schon mal - ich weiss es aber auch nicht mehr, warum wir hier bei textdata blieben. Ein möglicher Grund: Man kann z.B. bei Teil von eine zeichengetrennte Mehrfachnennung erlauben oder man kann neben der reinen Verknuepfung zur loc_id auch anderen Text hineinschreiben. Sauberer erschiene auch mir die reine intdata. Fuer meine eigenen Zwecke ist es belanglos, ich arbeite anders. > 600700000 Einwohnerzahl > 600800000 Höhenangabe in Metern > 610000000 Fläche in km² > 650700001 Ungefähre Einwohnerzahl > 650800001 Maximale Höhe > 650800002 Minimale Höhe > 650800003 durchschnittliche Höhe > 650800004 Höhe am Referenzpunkt > 650800005 Höhe an der angegebenen Koordinate > Diese gehören sämtlich in den Bereich geodb_intdata. Einwohner sind sicher intdata. Hoehe kann auch real sein, Flaeche sollte mit zunehmender Ortsaufloesung in real sein, denn irgendwann ist man auf Quadratmetergenauen Angaben fuer Grundstuecke angekommen. Beliebiges Beispiel aus LI.sql: INSERT INTO geodb_intdata VALUES(32384,600700000,4141,null,null,'3000-01-01',300500000); INSERT INTO geodb_floatdata VALUES(32384,610000000,10.3,null,null,'3000-01-01',300500000); > Ich weiß, dass das erstmal für Inkompatiblitäten sorgen wird, aber mein > Vorschlag wäre dennoch, dies demnächst zu ändern und die entsprechenden > Datensätze zu verschieben. Keine Ahnung, wie aktiv derzeit die opengeodb genutzt wird. Auf der Liste hier ist es oft ja sehr ruhig. Daher wuerden sich vielleicht nur sehr wenige an Aenderungen stoeren. Aber jemand muesste sie machen - und ich stecke tags in der Arbeit, abends in der Altbausanierung, nachts im Bett, morgens bei der Familie. So viel Zeit bleibt mir derzeit nicht... Komm zum Waendestreichen, dann streiche ich die Fehler im SQL-Code ;-) -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger -- Mailingliste OpenGeoDB Listenadresse: opengeodb@... Informationen: http://opengeodb.de Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)
	Re: textdata vs. intdata by Peter Wendorff :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Martin Trautmann schrieb: >> Obwohl ich die Frage sicherlich schon früher gestellt habe - jedenfalls >> meine ich mich daran erinnern zu können: >> >> Gibt es einen Grund, warum diverse int-Typen in geodb_textdata liegen? >> Allen Voran Verknüpfungen zu anderen Entities per loc_id. >> Insbesondere also: >> 400100000 Teil von >> 400200000 Ebene >> > > Ich glaube, die Frage hatten wir schon mal - ich weiss es aber auch nicht mehr, warum wir hier bei textdata blieben. Ein möglicher Grund: Man kann z.B. bei Teil von eine zeichengetrennte Mehrfachnennung erlauben oder man kann neben der reinen Verknuepfung zur loc_id auch anderen Text hineinschreiben. Sauberer erschiene auch mir die reine intdata. > Die Mehrfachnennung ist aber doch sonst nicht zwangsläufig verboten - Postleitzahlen sind auch jetzt bereits großteils in mehreren Datensätzen genannt. Also einfach mehrere Datensätze gleichen Typs definieren - ist meiner Meinung nach wesentlich sauberer. > Fuer meine eigenen Zwecke ist es belanglos, ich arbeite anders. > > >> 600700000 Einwohnerzahl >> 600800000 Höhenangabe in Metern >> 610000000 Fläche in km² >> 650700001 Ungefähre Einwohnerzahl >> 650800001 Maximale Höhe >> 650800002 Minimale Höhe >> 650800003 durchschnittliche Höhe >> 650800004 Höhe am Referenzpunkt >> 650800005 Höhe an der angegebenen Koordinate >> > > >> Diese gehören sämtlich in den Bereich geodb_intdata. >> > > Einwohner sind sicher intdata. Hoehe kann auch real sein, Flaeche sollte mit zunehmender Ortsaufloesung in real sein, denn irgendwann ist man auf Quadratmetergenauen Angaben fuer Grundstuecke angekommen. > Dann gehören Höhe und Fläche nach floatdata, > Beliebiges Beispiel aus LI.sql: > INSERT INTO geodb_intdata VALUES(32384,600700000,4141,null,null,'3000-01-01',300500000); > INSERT INTO geodb_floatdata VALUES(32384,610000000,10.3,null,null,'3000-01-01',300500000); > > >> Ich weiß, dass das erstmal für Inkompatiblitäten sorgen wird, aber mein >> Vorschlag wäre dennoch, dies demnächst zu ändern und die entsprechenden >> Datensätze zu verschieben. >> > > Keine Ahnung, wie aktiv derzeit die opengeodb genutzt wird. Auf der Liste hier ist es oft ja sehr ruhig. Daher wuerden sich vielleicht nur sehr wenige an Aenderungen stoeren. > > Aber jemand muesste sie machen - und ich stecke tags in der Arbeit, abends in der Altbausanierung, nachts im Bett, morgens bei der Familie. So viel Zeit bleibt mir derzeit nicht... Komm zum Waendestreichen, dann streiche ich die Fehler im SQL-Code ;-) > Ich vermute, dass etliche Scripts schlichtweg geschrieben sind und als solche genutzt werden. Unter Umständen funktionieren aber eben gerade diese nicht mehr. Das Verschieben in die andere Tabelle dürfte recht simpel gehen - das sind einzelne SQL-Befehle, die die Daten kopieren (und weitere zum löschen). Ich würd die SQL-Befehle zur Verfügung stellen, aber das ist nur sinnvoll, wenn diese Änderung Konsens ist. Gruß Peter -- Mailingliste OpenGeoDB Listenadresse: opengeodb@... Informationen: http://opengeodb.de Mit freundlicher Unterstütztung von php::bar (http://phpbar.de)