Fußballfelder im Deutschen Mapnik-Style

Surface=grass ist sogar Vorraussetzung dafür, dass die Linien dargestellt werden.

Edit: Ah sorry hatte es falsch in Erinnerung… ja da ging es nur um die Farbe unter den linien. Aber grass verhindert auf jedenfall nicht die linien.

Also im deutschen Stil spielen noch die Innenwinkel, die Längen der Seiten und die Gesamtfläche eine Rolle, alles in bestimmten Toleranzintervallen.
Wer es genauer wissen will kann ja im dt. Stil nach sports-soccer suchen. Die Vorlage dafür stammt aus dem französischen Stil, der schon in cartocss vorliegt.

“Profi”-Tipp: am besten einen Platz bei dem es funktioniert per Copy und Paste an den Zielort verfrachten (sofern passend natürlich!) :sunglasses:

Es reicht sogar ein einfaches leisure=pitch. Mehr braucht es überhaupt nicht.

Ohne sport=* oder auf was spielst du an? Das würde mich sehr wundern, da pitch ja für sehr viele verschiedene Felder/Plätze steht. Tennis hat ja z.B. auch einen eigenen style.

sport=soccer oder tennis muss sein

Meine geometrische Vorstellungsfähigkeit ist gerade blockiert…

Könnte bitte jemand ohne Blockade mal im Stil ganz unten die Berechnung der Winkel dahingehend überprüfen, ob die auch mit negativen Breitengraden funktioniert?

Alternativ: Kennt jemand ein bemaltes Fußballfeld in Südafrika oder Australien? Vielleicht ist der Gegenbeweis leichter :wink:

Grüße, Max

Zumindest in Erlensee wird ein einfaches leisure=pitch ohne nichts bereits als Fußballfeld gerendet. Es sei denn ich übersehe etwas.

Da liegt noch ein leisure=stadium mit sport=soccer drunter oder drüber.

In Brasilien ist aber lat und lon negativ, in Australien nur lat. :sunglasses:

Man müsste also mal alle Quadanten checken:


lat  lon  Linien 
 +   +     yes
 +   -     yes
 -   +     yes
 -   -     yes

Hier ein Platz in Südamerika mit Linien:
http://openstreetmap.de/karte.html?zoom=17&lat=-33.39574&lon=-70.49996&layers=B000TT

Danke. Ich glaube, das war ein Holzweg…

Habs durchprobiert, 2 Felder, einmal links- und einmal rechtsdrehend in jedem Quadranten: Da werden 2 Winkel berechnet, angle_diff und angle. “angle_diff” ist richtig, damit wird ermittelt, ob das Ding ungefähr ein Rechteck ist. “angle” nimmt auf der Südhalbkugel merkwürdige Werte an, 270 z.B. Damit werden aber nur die Linien in die Ausrichtung des Spielfeldes gedreht, und ich kann mir nicht vorstellen, dass Mapnik mit “290° nach links drehen” Schwierigkeiten hätte.

Grüße, Max

Edit: Auch in Brasilien gibt es welche

Das scheint mir eher ein Zufallstreffer zu sein… :confused:
Gibt es auch ein recheckiges Spielfeld mit Linien in Brasilien?

Ich hab ein hübsch und ein weniger hübsch gerendertes gefunden. Allerdings geschätzt 20-30 unmarkierte. Hab allerdings nicht nachgesehen, ob da überall auch sport=* eingetragen ist.

Ihr könnt ja noch etwas mit Overpass Turbo rumspielen. Bei den Einstellungen unter Karte gilt es


http://{s}.tile.openstreetmap.de/tiles/osmde/{z}/{x}/{y}.png

als Kachelserver einzustellen. Abfrage mit:


(way({{bbox}})[leisure=pitch][sport=soccer][name];>;);out meta;

oder für “Name egal” einfach das [name] rauswerfen.

Da findet man recht fix einige Beispiele:

http://www.openstreetmap.org/way/231001446
http://www.openstreetmap.org/way/230996845
http://www.openstreetmap.org/way/197101255
http://www.openstreetmap.org/way/273618870
http://www.openstreetmap.org/way/231005583

Die Winkel lassen mir doch keine Ruhe…

Der Stil erkennt Fussballfelder unter anderem daran, dass der Winkel zwischen der ersten und der zweiten Linie ca. 90° beträgt. Dazu rechnet er mit st_azimuth die Winkel (a12 und a23) der beiden Linien gegen die Senkrechte aus, bildet die Differenz und nimmt dann den Betrag.

Bei einem Polygon aus (-2 -3) (-3 -2) (-2 -1) (-1 -2) geht das schief…

Die Winkel:

osm=> select degrees(st_azimuth(st_pointn(way2,1),st_pointn(way2,2))) as a12 , degrees(st_azimuth(st_pointn(way2,2),st_pointn(way2,3))) as a23 
           from (select ST_ExteriorRing('POLYGON((-2 -3,-3 -2,-2 -1,-1 -2,-2 -3))') as way2) as foo1;
 a12 | a23 
-----+-----
 315 |  45

Der Betrag (die Codestücke hier sind so ziemlich das gleiche wie im deutschen Stil)

osm=> select abs(a12-a23) as angle_diff,(a12+a23+90)/2 as angle  
                    from (select degrees(st_azimuth(st_pointn(way2,1),st_pointn(way2,2))) as a12 , degrees(st_azimuth(st_pointn(way2,2),st_pointn(way2,3))) as a23
                             from (select ST_ExteriorRing('POLYGON((-2 -3,-3 -2,-2 -1,-1 -2,-2 -3))') as way2) as foo1) as foo2;
 angle_diff | angle 
------------+-------
        270 |   225

Als Bild:

Allerdings ist dieser Fehler überall drin, wenn man irgendwo anfängt, wo die beiden Linien links und rechts der Senkrechten liegen, auch auf der Nordhalbkugel. Gibt es irgendeinen Grund, warum die Linien in Südamerika häufiger so liegen als in Europa? Z.B. weil ST_ExteriorRing() immer näher bei der Nulllinie anfängt, oder weil osm2pgsql Flächen so importiert? Falls das nicht so ist, ist zwar ein potentieller Fehler, aber keine Erklärung gefunden :wink:

Grüße, Max

Mit einem angle_diff von 270 wird da erstmal nichts angezeigt, der Winkel muss lt. Bedingung im Stil im Wertebereich 86 bis 94 (einschl.) liegen. Vielleicht müsste man für Werte x > 180° entsprechend mit 360° - x rechnen?

Auf jeden Fall hört sich das nach einem neuen Trac-Ticket (http://trac.openstreetmap.fr) für Komponente “style osmfr” und später auch für den deutschen Stil an.

Edit: Github-Ticket für den frz. Cartocss-Stil an: https://github.com/cquest/osmfr-cartocss

Vielleicht verlaufe ich mich auch in Rechnerei… Ich habe noch eine andere Theorie, die was mit Mercator und Äquatornähe zu tun hat (da sind die Felder ja deutlich kleiner). Es wäre also gut zu wissen, ob das wirklich die Ursache für Brasiliens Fussballfelder ist…

Könnte bitte mal jemand, der den Planeten in einer Datenbank hat diese Abfrage ausführen:

select osm_id,way_area,d12,d23,d13,a12,a23, abs(a12-a23) as angle_diff, (a12+a23+90)/2 as angle from (select *, st_npoints(way2) as nb, ST_Distance(st_pointn(way2,1),st_pointn(way2,2)) as d12, ST_Distance(st_pointn(way2,3),st_pointn(way2,2)) as d23, ST_Distance(st_pointn(way2,1),st_pointn(way2,3)) as d13, degrees(st_azimuth(st_pointn(way2,1),st_pointn(way2,2))) as a12, degrees(st_azimuth(st_pointn(way2,2),st_pointn(way2,3))) as a23 from (select *, st_area(way) as way_area, ST_ExteriorRing(ST_SimplifyPreserveTopology(way,100)) as way2 from (select osm_id,(st_dump(way)).geom as way from osm_polygon where osm_id in ( 17752531 , 123121774,231001446,230996845,197101255,273618870,231005583,119202184 )) as dump ) as simplified) as simplified2;
  osm_id   |     way_area     |       d12        |       d23        |       d13        |       a12        |       a23        |    angle_diff    |      angle       
-----------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------
  17752531 | 16016.2461500168 |  100.52086400347 | 158.917015451705 | 189.030475056445 |  58.874951968682 | 148.205193244697 | 89.3302412760151 |  148.54007260669
 123121774 |  15899.274600029 | 101.455847539591 |  156.94597350703 | 186.501847711844 | 76.7869662763087 | 167.043144041439 | 90.2561777651306 | 166.915055158874

Anzupassen wäre vielleicht der Tabellenname (“osm_polygon”). Die heisst ja oft anders… Die beiden Felder 17752531 und 123121774 sind Fussballplätze in Deutschland mit Bemalung, die IDs 231001446, 230996845, 197101255, 273618870, 231005583 und 119202184 sind aus couchmappers Overpass-Abfrage oben und Beitrag Nr 1.

Grüße, Max

Edit: way_area noch eingebaut

Hier mal die Abfrage für die Fußballplätze in Brasil (ohne DE):


  osm_id   |     way_area     |       d12        |       d23        |       d13        |       a12        |       a23        |    angle_diff    |      angle       
-----------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------
 197101255 | 16994.6647500047 | 150.828791018097 | 115.040033466692 |  188.17583612099 | 8.19134561586987 | 99.1380794573781 | 90.9467338415083 |  98.664712536624
 273618870 | 12059.5242999632 | 137.322061228193 | 86.6285478347115 | 164.905612396601 | 71.6508133621427 |  159.64677085194 | 87.9959574897978 | 160.648792107042
 231001446 | 19908.9312499742 | 199.745402950752 | 99.8229081925917 | 223.295823964515 |  5.2105300844574 | 95.2131363754718 | 90.0026062910145 | 95.2118332299646
 230996845 | 11714.3916000273 | 85.0605255098882 | 137.718307425121 | 161.867862159442 | 86.1644180784049 | 176.165446178967 | 90.0010281005616 | 176.164932128686
 231005583 | 11060.2094499654 |   83.10915352695 |   133.0712399434 | 156.895026370712 | 21.4928819604532 | 111.490387447387 | 89.9975054869339 |  111.49163470392
 119202184 | 9907.40950006523 | 120.459414327406 | 82.2493823689554 | 145.855815105799 | 31.1326113281921 | 121.136984971288 | 90.0043736430962 |  121.13479814974
(6 Zeilen)


area[name="Brasil"];(way(area)[leisure=pitch][sport=soccer];>;);out meta;

Export → Rohdaten direkt von Overpass API → Link kopieren, mit wget downloaden und mit osm2pgsql laden. Das geht recht fix. Ergibt dann 6842 Polygone.

Bedingungen zum Anzeigen:


[d12>130][d12<200][d23>68][d23<160][d13>150][d13<250] { /* 1>2 = length / 2>3 = width */
[d23>130][d23<200][d12>68][d12<160][d13>150][d13<250] { /* 1>2 = length / 2>3 = width */

d12, d13, d23 sollten je nachdem, wie das Feld in OSM gezeichnet wurde, Länge, Breite und Diagonale darstellen.

Die way_area sollte keine Rolle spielen, da der Stil zwar 3 Fälle unterscheidet (kleiner 12000, 12000…17000 und größer 17000), aber damit praktisch alle Möglichkeiten abdeckt.

Danke, die Winkel waren ne lustige Theorie, aber sind unschuldig :wink:

Das Feld aus Nr. 1 (119202184) sollte an den Längen scheitern.
Das grosse Feld 231001446 wird bemalt. 230996845 auch…

Ich schätze die Mercatorprojektion ist schuld. Diese “mindestens 130 Einheiten”-Regel passt in Deutschland und Frankreich ganz gut. Da sind 130 Einheiten ca 85 Meter (130cos(50°)). Ein Spielfeld am 20. Breitengrad in Rio muss mindestens 130cos(20°)=122 Meter lang und 68*cos(20°)=63 Meter breit sein, um als ordentliches Spielfeld zu gelten.

Mit Transformation von 900913 zu 4326 sieht das dann so aus:


  osm_id   |     way_area     |      d12      |      d23      |      d13      |       a12        |       a23        |    angle_diff    |      angle       
-----------+------------------+---------------+---------------+---------------+------------------+------------------+------------------+------------------
 197101255 | 16994.6647500047 | 130.989958189 |  99.909079274 | 163.424551098 | 8.19134561586987 | 99.1380794573781 | 90.9467338415083 |  98.664712536624
 273618870 | 12059.5242999632 | 117.129017319 |  73.889809564 | 140.655974389 | 71.6508133621427 |  159.64677085194 | 87.9959574897978 | 160.648792107042
 231001446 | 19908.9312499742 | 173.734651874 |  86.824652102 | 194.218280395 |  5.2105300844574 | 95.2131363754718 | 90.0026062910145 | 95.2118332299646
 230996845 | 11714.3916000273 |  73.973557642 | 119.767205081 | 140.768918464 | 86.1644180784049 | 176.165446178967 | 90.0010281005616 | 176.164932128686
 231005583 | 11060.2094499654 |  72.295788933 | 115.757416149 | 136.481096522 | 21.4928819604532 | 111.490387447387 | 89.9975054869339 |  111.49163470392
 119202184 | 9907.40950006523 | 110.831654583 |  75.675712367 | 134.198065185 | 31.1326113281921 | 121.136984971288 | 90.0043736430962 |  121.13479814974
(6 Zeilen)

Das passt dann auch zu den Werten, die mir JOSM anzeigt. Bedingung und SQL Statement im frz+dt. Stil müssten dann wohl überarbeitet werden.


ST_Distance_sphere(st_transform(st_pointn(way2,1),4326),st_transform(st_pointn(way2,2),4326)) as d12, 
ST_Distance_sphere(st_transform(st_pointn(way2,3),4326),st_transform(st_pointn(way2,2),4326)) as d23, 
ST_Distance_sphere(st_transform(st_pointn(way2,1),4326),st_transform(st_pointn(way2,3),4326)) as d13,