Deutscher Stil: ele mit vielen Nachkommastellen

Communities Deutschland (Germany)
1

Hallo,

beim deutschen Stil werden die beiden Berge hier mit ziemlich vielen Nachkommastellen angezeigt:
http://openstreetmap.de/karte.html?zoom=16&lat=49.54851&lon=7.27845&layers=B000TT

Ich schätze mal, dass da intern mit float/double gearbeitet wird und für die Ausgabe keine definierte Zahl an Nachkommastellen festgelegt ist (oder festgelegt werden kann?).
Kann mir jemand einen Tipp geben, ob das ein Bug in Mapnik oder im deutschen Stil ist und wo ich am besten den Bugreport aufmachen kann? Bisher hatte ich nach mapnik und textsymbolizer gesucht, kann die Treffer aber nicht so recht einordnen. Auf openstreetmap.org tritt das Problem übrigens nicht auf.

Danke im Voraus!

Gruß,
mmd

2

Für den deutschen Stil ist Sven Geggus verantwortlich. Der ele-Wert wird von mapnik 1:1 unformatiert aus der Postgres-Datenbank übernommen.Dort ist er als typ Text definiert.

HTH,
ajoessen

3

Sven meinte dazu, dass ele in der Datenbank doch als Fließkommazahl abgelegt ist. Die Lösung sieht aktuell so aus: der ele-Wert wird gerundet, Berge werden jetzt auf den Meter genau angezeigt.

Vielen Dank an Sven für den schnellen Fix!

4

Nö.

(Berg-)Höhen werden seit altersher mit (bis zu) 2 Nachkommastellen (“centimetergenau”) angegeben,
so ist das “alle Nachkommastellen kappen” kein Fix, sondern bestenfalls ein workaround.

5

hmm, dann müsste das “bis zu 2 Nachkommastellen” nur in ein performantes SQL-Statement für Postgres übersetzt werden. Hab’ leider lokal keine Installation zum Ausprobieren.

Klappt das evtl. schon mit: select TO_CHAR(ele,‘FM9999D99’) as ele from planet_osm_point where … ?

6

Ja.

=> select round(1.23456789,2);
 round 
-------
  1.23

Der Haken daran ist, dass postgis über diesen sehr häufigen Fall stolpert, weswegen Import als real oder int vermutlich einfacher ist (sofern das import-Tools toleranter ist):

=> select round('1.23456789 Meter',2);
ERROR:  invalid input syntax for type numeric: "1.23456789 Meter"

Alternativ müsste man irgendwo zwischen Import und Rendern einen Putzjob unterbringen, der alles bereinigt, was sich nicht als Gleitkommazahl interpretieren lässt.

Grüße, Max

7

Wenn ich das richtig verstanden habe, liegen die Höhenwerte schon als Fließkommazahl vor, d.h. mit Buchstaben oder anderen Sonderzeichen braucht man sich nicht mehr herumzuschlagen.

Ist TO_CHAR(ele,‘FM9999D99’) für diese Konvertierung zu gebrauchen?

812 => ‘812’
812.1 => ‘812.1’
812.12 => ‘812.12’
812.123 => ‘812.12’

8

Jep. Ich wollts nur sagen, weil üblicherweise hat man ja ele als Text in der DB und dort fliegt man dann auf die Nase mit runden…

Ja, wäre zu gebrauchen.

9

Hat leider nicht funktioniert, siehe erstes Beispiel unten aus dem Ausschnitt, den mir Sven gemailt hat.
Da wird immer noch ein Komma ausgegeben, obwohl es keine Nachkommastelle gibt.

Gibt es noch andere Vorschläge/Ideen?


$ psql gis
psql (9.1.1)
Geben Sie »help« für Hilfe ein.

gis=# set lc_numeric='de_DE.UTF-8';
SET

gis=# select TO_CHAR(812::float,'FM9999D99');
to_char
---------
812,
(1 Zeile)

gis=# select TO_CHAR(812.1::float,'FM9999D99');
to_char
---------
812,1
(1 Zeile)

gis=# select TO_CHAR(812.12::float,'FM9999D99');
to_char
---------
812,12
(1 Zeile)

gis=# select TO_CHAR(812.123::float,'FM9999D99');
to_char
---------
812,12
(1 Zeile)

Gruß,
mmd

10

Oh… Peinlich, den Normalfall nicht getestet…

Wie wäre es damit?

select round((812::float)*100)/100;
      812

select round((812.1::float)*100)/100;
    812.1

select round((812.12::float)*100)/100;
   812.12

select round((812.123::float)*100)/100;
   812.12