> Gesendet: Montag, 13. Januar 2025 um 11:45 > Von: "Frederik Ramm" <[email protected]> > An: "Christian Müller via Talk-de" <[email protected]> > Betreff: Re: [Talk-de] Genauigkeit der Koordinaten in der OSM-DB > (Nachkommastellen) > > In OSM werden die Daten intern nicht als float-Werte gespeichert, > sondern als Ganzzahlen, und vorher mit 1E7 multipliziert: > > https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/concerns/geo_record.rb#L17-L20 > > Bye > Frederik
Danke für den Link. Interessanterweise trifft das nicht alle Strukturen der DB: https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/db/structure.sql#L1006 https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/app/models/node.rb (Wiederholung im header comment) Dort ist zu erkennen, das für die Tabellen * nodes (obige links), gps_points und notes integer, aber für * gpx_files, diary_entries (link unten) double precision verwendet wird. https://github.com/openstreetmap/openstreetmap-website/blob/5d76ec051e2c429b6647401674e13688c1251956/db/structure.sql#L716 Die Bedeutung/Länge des Typs integer im Kontext SQL ist implementations-abhängig. Bei MS ACCESS wurden beispielsweise 2 byte verwendet, bei MSSQL, MySQL u.ä. 4 byte. Quelle: https://www.w3schools.com/sql/sql_datatypes.asp Bei Oracle ist INTEGER (entgegen ANSI) gar ein Alias für NUMBER(38): The INTEGER data type is an ANSI standard data type, which means it is in all SQL databases. However, in Oracle, it's a synonym for NUMBER(38). This means that if you declare an INTEGER column, Oracle is actually declaring a NUMBER column with 38 digits and 0 decimal places. Quelle: https://www.databasestar.com/oracle-data-types/#Numeric_Data_Types (dort erhält man den 4 byte Typ mit Alias BINARY_INTEGER) Seit April 2009 wird für OSM PostgreSQL verwendet. Quelle: https://wiki.openstreetmap.org/wiki/Database Und laut dem dort angegebenen Schema, siehe https://wiki.openstreetmap.org/wiki/File:OSM_DB_Schema_2016-12-13.svg werden latitude und longitude der Tabelle nodes als Spalten vom Typ "int4" definiert. Falls das noch so ist, trifft diese Erläuterung zu: "SQL only specifies the integer types integer (or int), smallint, and bigint. The type names int2, int4, and int8 are extensions, which are also used by some other SQL database systems." Quelle: https://www.postgresql.org/docs/current/datatype-numeric.html#DATATYPE-INT Mit int4 und dem Skalierungsfaktor 10.000.000 liegt demnach der Maximalwert für eine Längen/Breitenangabe bei 2^31-1 / 1E7 = 2.147.483.647 / 1E7 = 214,7483647 (Grad) Soll eine weitere Nachkommastelle abspeicherbar sein, also der Skalierungsfaktor 1E8 verwendet werden, ändert sich der Wertebereich unter Beibehaltung von int4 auf -21,47483648 ≤ x ≤ 21,47483647 was weder für Breitengrad- (-90 ≤ x ≤ 90) noch Längen- gradwerte (-180.0 ≤ x ≤ 90) ausreichend wäre. Die ursprüngliche Rechnung, die sich auf die Mehrin- anspruchnahme bei Verwendung von "float64" anstatt "float32" bezog, ist also 1:1 übertragbar, falls das DB-Schema statt "int4" die Typen "bigint" bzw. "int8" zum Abspeichern von latitude und longitude einsetzen würde. Gruß _______________________________________________ Talk-de mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-de
