Fußballfelder im Deutschen Mapnik-Style

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, 

Gute Idee.

Jup, in Europa hätte auch das Maracana-Stadion mit seinen 110x75 Metern (echten Metern, in Deutschland wären das stolze 171x116 “Mercatoreinheiten”) das Kriterium für einen Fussballplatz erfüllt :wink:

Die Frage ist, wie kommt man da raus? In die Abfrage eine Transformation einbauen und dann die ganzen Faustregeln für die Grössen der Tennis-, Fussball-, Baseball- … plätze ändern. Das wird mühsam. Andererseits sicher zukunftsträchtig, falls mal eine WM in z.B. Katar bei 25° Nord stattfindet…

Grüße, Max

Ich hab mal in der mapnik-de-Liste das Problem geschildert… Da sollten Leute mitlesen, die beurteilen können, wie/ob das Problem zu lösen ist und ob Brasiliens Spielfelder für den deutschen Stil interessant sind.

Grüße, Max

Da schließe ich mich doch gerne an: http://trac.openstreetmap.fr/ticket/589

Ich antworte wie dort bereits geschrieben wohl besser hier im Forum.

Ich fürchte ich muss doch beginnen mehr im Forum mitzulesen. Mailinglisten sind Out, ich werde alt.

Zum Thema:

Ich habe das Lienienzeug ja nicht wirklich erfunden. Ich habe lediglich die relevanten Teile des xml Outputs von “carto” angewendet auf den franz. Stil in den deutschen Stil eingebaut.

Wenn das Problem wirklich die ST_Distance Funktion ist, dann haben wir ein Problem, denn dann dürfen wir nicht in Google Merkator rechnen sondern in einer jeweils lokal gültigen Längentreuen Projektion. EPSG:4326 ist da denk ich keine Option, die verzerrt ja noch schlimmer als Merkator.

Also brauchen wir zunächst eine psql funktion get_best_proj od so, die uns die Beste lokale UTM Projektion liefert um dann den Abstand in genau dieser zu berechnen.

Man könnte mal die Leute auf der FOSSGIS Liste fragen ob es sowas vielleicht schon gibt bevor man das Rad neu erfindet.

Eine zweite Idee wäre es st_transform auf EPSG:4326 und ST_Distance_Sphere bzw. ST_Distance_Spheroid zu verwenden.

Die relevante Datei ist übrigens hier:
http://svn.openstreetmap.org/applications/rendering/mapnik-german/inc-de/layer-landcover.xml.inc

Falls jemand ein diff schicken mag.

Gruss

Sven

Hallo Sven,

ich hab mal ein diff erstellt: link gelöscht

Ich habe leider kein zu ST_Distance_Sphere passendes ST_Area_Sphere gefunden, und die Fläche brauchen wir auch. Deshalb wird cos(lat) berechnet und mitgeschleift, in d12, d23 und d13 sollten jetzt echte Meter stehen und ein neues Feld “pitch_area” enthält die Spiefeldgröße in Quadratmetern.

Ich hoffe, Mapnik kann auch ein bisschen rechnen. Da kommt jetzt nämlich überall scale(0.15/[coslat]) vor. Diese Skalierungsfaktoren (hier 0.15) scheinen auch vom Breitengrad abhängig zu sein (das SVG-Symbol hat in Paris bei Zoom 16 die Größe 1).

Mein Problem: Ich kann das alles nicht testen. Hier liegt weder Brasilien noch Mapnik rum… Könnte also auch alles ganz schrecklich enden :wink:

Grüße, Max
*
Edit: Link zum diff gelöscht, war sowieso kaputt, ich probiers in einer Sandkiste auf dem Tileserver, die mir Sven freundlicherweise hingestellt hat*

Na ja, wenn die Längen in Meter vorliegen kann man die Fläche doch ganz normal karthesisch ausrechnen?!

Ich denke es wäre etwas direkter, wenn ich Dir einen Shellaccount auf dem tileserver einrichten würde, dann könntest Du in einer der Sandboxen die Änderungen selbst testen. Einverstanden?

Wenn ja, dann schicke mir bitte Deinen ssh-Schlüssel per Mail zu.

Gruss

Sven

So Leute Dank maxbe sollte das jetzt besser funktionieren. Seine Änderungen sind jetzt scharfgeschaltet.

Aufgefallen ist mir, dass das Konzept bei etwas unförmigen Feldern an seine Grenzen stößt:

http://map.gegg.us/?zoom=18&lat=69.68203&lon=19.0722

Was haltet ihr davon wenn wir einen tag marked=yes/no einführen. Dann könnte man das rendern der Linien unterbinden, wenn explizit marked=no dransteht.

Gruss

Sven

Wenn der tag angibt, das auf dem realen Feld Linien eingezeichnet sind, dann gerne.

Wenn der tag nur angeben soll, das keine Linien gezeichnet werden sollen (unabhängig vom Realweltzustand des Feldes), dann ist das tagging für den Renderer, und damit wäre ich massiv dagegen.

Ja sicher, was denn sonst? Ich denke inzwischen pitch_marking wäre der bessere tag.

Nö, so nicht. Ich sagte bereits, dass ich das im renderer so realisieren würde, dass ich nur dann keine Linien rendere, wenn explizit dransteht dass da keine sind. Denn oft ist es bei Fußballfeldern ja auch so, dass die nur on demand eingezeichnet werden. In der Karte sollten sie dann trotzdem auftauchen.

Generell finde ich aber renderer hints in der Datenbank nicht wirklich verwerflich, wenn sie als solche gekennzeichnet sind. Das hat ja ggfs. für die Nutzer der Daten sogar einen realen Wert.

Es gab sowas ja mal bei osmarender: http://taginfo.openstreetmap.org/keys/osmarender%3ArenderName

Immerhin noch 400 mal in der Datenbank!

Verwerfliches Tagging für den Renderer ist IMO etwas anderes. Ein Beispiel aus dem hier diskutierten Umfeld ist barrier=line. Diesen Müll gibt es laut taginfo über 6000 mal: http://taginfo.openstreetmap.org/tags/barrier=line

Gruss

Sven

+1 für pitch_marking.
Und in dem Sinne “Feld hat Platzlinien” ist es auch kein Render-Hint, sondern einfach ein Attribut des Platzes.

Ich glaube, das Problem der schiefen, unterkleinen und übergrossen Markierungen ist mit Tags nicht lösbar…

Die kommen ja nicht daher, dass der Platz in echt Striche hat oder nicht, sondern daher, dass da von den Machern des französischen Stils viel Ausprobieren und Erfahrung drin steckt, wie so ein Platz in Openstreetmap gemappt ist. Da kam wohl raus, dass die öfter zu breit als zu lang gemappt sind. Und so ergibt sich ein Label, das dann eher die Länge nutzt als die Breite.

Vielleicht sind Fussballplätze auch wirklich so, der Rasen ist ja immer grösser als das markierte Feld.

Man kann da jetzt noch rumdrehen und z.B. verlangen, dass ein Platz nur mit Markierungslinien versehen wird, wenn er höchstens ein Seitenverhältnis von 20:11 hat, oder die Markierungen generell kleiner oder grösser gestalten. Vermutlich muss man da sowieso noch dran drehen, wo man die Grenze für “ordentliche” Plätze zieht. Diese Werte wurden ja alle jetzt geändert, nach Umrechnen der alten Werte, Lektüre der Wikipedia, grosszügigem Aufschlag und Rundung.

Unabhängig davon kann es natürlich Sinn haben, die Plätze zu taggen, die überhaupt Striche haben. Ich sehe die Striche eher als Kartensignatur. So wie eine Gaststätte Messer und Gabel als Symbol hat, auch wenn es dort nur Gerichte gibt, die man mit dem Löffel ist. Aber man kann natürlich auch ein realistischeres Abbild der Welt anstreben :wink:

Grüße, Max

Das wird aber von den meisten missverstanden werden.

Das Problem ist einfach, dass insbesondere bei kleinen Dorf Vereinen, dass eigentlich nicht zu bestimmen ist. Unser 2. Feld wird hin und wieder für Spiele genutzt und dann gibt es Markierungen, aber oft sind auch keine da uns das ganze ist nur ein Trainingsplatz. Ganz zu schweigen von den Markierungen für die Jugend, wenn dann das halbe Feld als Kleinfeld markiert wird…

Das ist trotzdem sinnvoller als nur dort Linien zu rendern wo pitch_marking=yes dransteht. Die Linien sind ja in diesem Fall auf der Karte nicht dazu da die Wirklichkeit abzubilden sondern um zu zeigen “das ist ein Fußballfeld”. Wenn marked=no dransteht, dann bedeutet das aus meiner Sicht, dass das Feld nie markiert ist. Dann lassen wir das im Rendering weg.

Wo ist das Problem. Dann lässt man den Tag dort halt einfach ganz weg weil unbestimmt und wir rendern die Linien trotzdem, weil kein pitch_marking=no dransteht.

Sven