Hamburg mitten im Meer

chris66 wrote:

Hi,
aufgefallen ist es in meiner Garmin Karte aber auch in Mapnik ist es zu sehen:
http://www.openstreetmap.org/?lat=53.93 … 7&layers=M
Wo kommt das her?

Chris

Vlielleicht dies: http://www.openstreetmap.org/browse/relation/62782

Keine Ahnung... auf meiner Karte von vor 5h ist das Wasser so wie es sein soll.

Zu früh gefreut....ist doch da...

Jup ist tatsächlich ein Stadtteil von Hamburg 🙂, http://de.wikipedia.org/wiki/Hamburg-Neuwerk

Ah, ok. Zeigt mal wieder das place-Polygone (statt -Nodes) suboptimal sind.

Berlin gibts bei mir in der Karte auch zweimal...

chris66 wrote:

Ah, ok. Zeigt mal wieder das place-Polygone (statt -Nodes) suboptimal sind.

Also bestenfalls zeigt es, dass die meisten Renderer nur begrenzt gut mit den Polygonen umgehen können. Die Daten scheinen mir jedenfalls so durchaus korrekt und recht genau (wesentlich genauer jedenfalls als mit Place-Nodes), insofern würde ich da nichts dran ändern wollen.

Hallo Kollegen,

ich habe mir "Hamburg im Meer" auch vor kurzem angesehen. Das Taging ist schon korrekt. Die Auswirkung in diesem Fall aber nicht richtig sinnvoll.
Hat jemand eine Idee wie wir das OSM-konform lösen können?

ludwich

Ein spontaner Ansatz wäre das Hinzufügens eines Nodes, welcher die Stadtmitte repräsentiert, zu der Grenzrelation, und dann mit der Rolle admin_centre oder wie das heißt.

In Deutschland soll dies aber angeblich nicht verwendet werden. Weiß jetzt nicht gerade, wo es darüber mal eine Diskussion gab ...

errt wrote:

Also bestenfalls zeigt es, dass die meisten Renderer nur begrenzt gut mit den Polygonen umgehen können.

Was sollen die denn anders machen als den Namen in die Mitte des Polygons / der Teilpolygone zu zeichnen? 😉

chris66 wrote:

Was sollen die denn anders machen als den Namen in die Mitte des Polygons / der Teilpolygone zu zeichnen? 😉

... und wo ist deiner Meinung nach die "Mitte", wenn das Polygon nicht einem Vollmond, sondern eher einer Mondsichel ähnelt?

Gruss Christian

Na, irgend eine mathematisch sinnvolle Mitte halt. Eine die sich IM Polygon befindet. Hat aber mit dem aktuellen Problem
wenig zu tun. Im linken Teil-Polygon (Neuwerk) möchte man natürlich keinen Großstadt-POI Hamburg2 haben. 😉

stephan75 wrote:

Ein spontaner Ansatz wäre das Hinzufügens eines Nodes, welcher die Stadtmitte repräsentiert, zu der Grenzrelation, und dann mit der Rolle admin_centre oder wie das heißt.

+1

Chris

Hamburg hat eigentlich schon einen place-Node (http://www.openstreetmap.org/browse/node/20833623),
das place Tag an der Relation werde ich dann mal löschen.

Hallo Chris66,

wir haben 2 Relationen die einen Admin-Level 4 abbilden
Relation ID: 62782, Relation Name: Hamburg
Relation ID: 451087, Relation Name:Hamburg (Landmasse)

Wir könnten in eine Relation Bundesland/Adminlevel4 (Hamburg und Insel) mit einer enthaltene Relation(Hamburg ohne Insel)/Adminlevel6/place (KreisfreiStadt) anlegen?

ludwich

Wenn ich mich nicht ganz täusche sind an der Stelle in der Nordsee (Link von Post #1) 2 verschiedene Namen. Wenn man eine Zoomstufe heraus geht, wird aus "Hamburg" "Hamburg Neuwerk".

Neuwerk ist die 51676.
http://www.openstreetmap.org/browse/relation/51676

Zusammenfassung der Struktur "Hamburg"

Zur Diskussion sieht unten

-Die Anordnung ist hierarchisch, die bezeichnungen nur symbolisch

Relation␣ID:␣451087,␣"Hamburg␣(Landmasse)"␣=␣Adminlevel-4,␣AGS␣"02",␣Bundesland/State␣␣=␣Fläche(Hamburg␣und␣Nationalpark␣Hamburgisches␣Wattenmeer␣mit␣den␣Inseln␣Neuwerk,␣Scharnhörn,␣Nigehorn)
Relation␣ID:␣62782,␣Relation␣Name:␣Hamburg␣=␣Adminlevel-6,City,␣und␣Placenode
Relation␣"Bezirk␣Altona"␣(Adinlevel-9)
Relation␣"Bezirk␣␣Eimsbüttel"
Relation␣"Bezirk␣Hamburg-Nord"
Relation␣"Bezirk␣Wandsbek"
Relation␣"Bezirk␣Bergedorf"
Relation␣"Bezirk␣Harburg"
Relation␣"Bezirk␣Hamburg-Mitte"
Relation␣Neuwerk,␣Nigehörn,␣Scharnhörn␣(alle␣Adminlevel␣10)->␣nicht␣51676␣die␣enthält␣das␣komplette␣Naturschutzgebiet

Info
In Rostock wurde eine "Suburb" Relation übersichtlich angelegt, die die Stadtteile übersichtlich gliedert.
Ich habe jedenfalls noch eine Tabelle gefunden die für Hamburg einen Adminlevel 4 für ausreichend hält weil das ja mit Hamburg identisch wäre. Ich meine das sollten wir wegen des NSG und der Inseln ändern und eine Adminlevel 6 Ebene "kreisfrei" einziehen.

Siehe auch
http://wiki.openstreetmap.org/wiki/DE:Grenze
"entfällt, da Stadtgebiet = Bundesland: admin_level=4" <---- Stimmt so nicht mehr!

Wie seht ihr das ?

Ludwich

Nachtrag der Stadtstruktur:

Bundesland;␣Stadt(Kreisfrei);␣Stadtbezirk;␣Stadtteil;␣Relation
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Hamburg-Altstadt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣HafenCity;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Neustadt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣St.␣Pauli;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣St.␣Georg;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Hammerbrook;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Borgfelde;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Hamm;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Horn;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Billstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Billbrook;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Rothenburgsort;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Veddel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Wilhelmsburg;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Kleiner␣Grasbrook;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Steinwerder;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Waltershof;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Finkenwerder;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Mitte;␣Neuwerk;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Altona-Altstadt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Sternschanze;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Altona-Nord;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Ottensen;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Bahrenfeld;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Groß␣Flottbek;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Othmarschen;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Lurup;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Osdorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Nienstedten;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Blankenese;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Iserbrook;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Sülldorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Altona;␣Rissen;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Eimsbüttel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Rotherbaum;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Harvestehude;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Hoheluft-West;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Lokstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Niendorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Schnelsen;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Eidelstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Eimsbüttel;␣Stellingen;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Hoheluft-Ost;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Eppendorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Groß␣Borstel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Alsterdorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Winterhude;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Uhlenhorst;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Hohenfelde;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Barmbek-Süd;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Dulsberg;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Barmbek-Nord;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Ohlsdorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Fuhlsbüttel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Hamburg-Nord;␣Langenhorn;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Eilbek;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Wandsbek;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Marienthal;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Jenfeld;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Tonndorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Farmsen-Berne;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Bramfeld;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Steilshoop;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Wellingsbüttel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Sasel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Poppenbüttel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Hummelsbüttel;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Lemsahl-Mellingstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Duvenstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Wohldorf-Ohlstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Bergstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Volksdorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Wandsbek;␣Rahlstedt;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Lohbrügge;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Bergedorf[3];␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Curslack;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Altengamme;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Neuengamme;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Kirchwerder;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Ochsenwerder;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Reitbrook;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Allermöhe[4];␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Billwerder;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Moorfleet;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Tatenberg;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Spadenland;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Bergedorf;␣Neuallermöhe[5];␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Harburg;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Neuland;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Gut␣Moor;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Wilstorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Rönneburg;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Langenbek;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Sinstorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Marmstorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Eißendorf;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Heimfeld;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Moorburg;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Altenwerder;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Hausbruch;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Neugraben-Fischbek;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Francop;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Neuenfelde;␣R()
Hamburg;␣Freie␣und␣Hansestadt␣Hamburg;␣Harburg;␣Cranz;␣R()

Bzgl. der Garmin-Adresssuche erfolgt in der FZK für Hamburg eine Sonderbehandlung:

1. Hamburg (Sonderfall):
   
2. Die Bezeichnung "Hamburg" gibt es nur im "admin_level=4".
   
3. Im "admin_level=9" gibt es "Hamburg-Mitte" und "Hamburg-Nord".
   
4. Für die Adresssuche wird deshalb das "admin_level=4" verwendet.
   

mkgmap:country=DEU & mkgmap:admin_level4=Hamburg {set mkgmap:city='${mkgmap:admin_level4}' }

Gruß Klaus

chris66 wrote:

Hamburg mitten im Meer

Die automatische Berechnung des Ortes, an dem der Name eines Polygons gerendert wird, ist IMHO eine suboptimale Eigenschaft von OSM. Auch ich bin schon einige Male darüber gestolpert und habe vier Nachteile ausgemacht - und zwar nicht nur in diesem Beispiel:

1) Die Namen erscheinen an unpassenden Orten in der Karte. Dies kann beispielsweise außerhalb der bezogenen Fläche oder unmittelbar neben einer Bezeichnung des Nachbarortes sein. Das verwirrt beim Betrachten der Karte. Oder die Benamung erscheint an einer Stelle, die mit vielen weiteren Objekten überfrachtet ist und diese verdeckt. Eine Verschiebung an eine Stelle mit weniger Objekten würde mehr Infos in der Karte belassen und z.B. den Namen der Stadt in der Karte deutlicher wahrnehmbar machen.
2) Es lässt sich nicht ausmachen, welches Objekt zu dem gerenderten Namens gehört. Denn beim Heranzoomen ist im Editor ist nichts zu finden. Das ist für Anfänger verwirrend, die beispielsweise Falschschreibungen korrigieren möchten. Und selbst die Profis tun sich schwer, wie dieses Beispiel zeigt.
3) Gleiche geografische Objekte werden zweimal erfasst - nämlich als Punkt und als Polygon - und daher auch zweimal gerendert. Namen von gleichen geografischen Objekte sollten aber nur einmal gerendert werden.
4) Die im Punkt gespeicherten Infos stehen dem Polygon nicht zur Verfügung - und umgekehrt.

Als einzige Abhilfe sehe ich da eine Multipolygon-Relation, in welche der zugehörige Punkt grundsätzlich als Member aufgenommen wird. Dieser Punkt kann dann vom Renderer als Label und damit als derjenige Ort angesehen werden, an dem der Name zu rendern ist. Möglicherweise nennt man dieses Tag sogar Label. Jetzt wird das geografische Objekt nicht mehr als zwei, sondern nur noch als ein Objekt aufgefasst und repräsentiert, in dem der ursprünglich zusätzliche Punkt nur noch Member ist. Damit wären alle vier genannten Probleme beseitigt:

1) Der User kann den Punkt des Renderns möglichst günstig wählen.
2) Beim Heranzoomen des Namens wird im Editor immer ein Punkt gefunden, mit dessen Hilfe das Objekt identifizert werden kann.
3) Gleiche geografische Objekte werden nur noch durch ein Objekt repräsaentiert und nur einmal gerendert.
4) Die im Punkt gespeicherten Infos stehen auch dem Polygon zur Verfügung - und umgekehrt.

Die Vorgehensweise, ein Label zur Verortung von Benamung, Beschreibung oder von flächigen Objekten zu nutzen, wird bei bei vielen Programmen mit ähnlicher Problemstellung genutzt, z.B. beim Computer Aided Design (CAD). Wenn sich dies also schon mehrfach als die beste Methode herauskristallisiert und daher etabliert hat, spricht doch nichts dagegen, auch bei OSM so zu verfahren. Zudem finden sich Nutzer aus diesen anderen Programmen schneller zurecht (und umgekehrt).

Gruß
Tirkon

Nahmd,

Tirkon wrote:

Die automatische Berechnung des Ortes, an dem der Name eines Polygons gerendert wird, ist IMHO eine suboptimale Eigenschaft von OSM.

Nein. Es ist der richtige Weg.

Die zur automatischen Berechnung der Position verwendeten Algorithmen sind noch nicht perfekt – aber die können ja nur besser werden.

1) […] Eine Verschiebung an eine Stelle mit weniger Objekten würde mehr Infos in der Karte belassen und z.B. den Namen der Stadt in der Karte deutlicher wahrnehmbar machen.

Mit weniger Objekten in welcher Karte?

Du hast das Label in einen Wald geschoben, “weil da ja nichts ist”. Ich sitze aber an der Imkerkarte und benamse genau da die Bienenstöcke – da wirst Du Verständnis haben, dass ich das Label verschiebe über das von Dir detailreich Industriegebniet mit vielen POIs – das mich aber nicht interessiert und in meiner Karte nur ein grauer Fleck ohne irgend ein Label ist.

Als einzige Abhilfe sehe ich da eine Multipolygon-Relation, in welche der zugehörige Punkt grundsätzlich als Member aufgenommen wird. Dieser Punkt kann dann vom Renderer als Label und damit als derjenige Ort angesehen werden, an dem der Name zu rendern ist. Möglicherweise nennt man dieses Tag sogar Label.

Ein angemessenerer Name ist “rendererhint:mapnic:defaultstyle:2012-06”. Denn ich setze ein ganz anderes Label an eine völlig andere Stelle.

[…]
4) Die im Punkt gespeicherten Infos stehen auch dem Polygon zur Verfügung - und umgekehrt.

Und aus diesem Grund sollten an den Punkt keinerlei Geo-Informationen gespeichert werden. Du kannst natürlich den Biegeradius und Fontgröße und Orientierung dranspeichern – es ist ja ein reines Displayfeature.

Die Vorgehensweise, ein Label zur Verortung von Benamung, Beschreibung oder von flächigen Objekten zu nutzen, wird bei bei vielen Programmen mit ähnlicher Problemstellung genutzt, z.B. beim Computer Aided Design (CAD). Wenn sich dies also schon mehrfach als die beste Methode herauskristallisiert und daher etabliert hat, spricht doch nichts dagegen, auch bei OSM so zu verfahren. Zudem finden sich Nutzer aus diesen anderen Programmen schneller zurecht (und umgekehrt).

Ja. Um bei dem Vergleich zu bleiben: die malen auch genau eine bestimmte Karte. Und stellen nicht eine Datenbasis zusammen, aus der viele verschiedene Karten erstellt werden können.

Gruß Wolf

Netzwolf wrote:

Tirkon wrote:

Die automatische Berechnung des Ortes, an dem der Name eines Polygons gerendert wird, ist IMHO eine suboptimale Eigenschaft von OSM.

Nein. Es ist der richtige Weg.

Kommt drauf an. 😉
Bei Flächen wie Wald, Wüste etc. ist es im Prinzip egal wo der Name steht, da kann man automatisch ausrichten
lassen. Bei Place-Polygonen sollte der Name im Stadtzentrum stehen. Wobei die Lösung mit dem place-Node und diesen
als Admin-Centre dem boundary-Poly zuzuordnen ja auch zufriedenstellend ist.

Chris

Hallo Mapper

Ich möchte die Fragestellung noch mal auf den Kern bringen:

Ist es "richtig" das Hamburg nur einen Admin Level 4 benötigt?
Angesichts den Tatsache das das Bundesland "Hamburg" aus Hamburg und der exclave "Neuwerk" besteht kann diese Aussage in meinen Augen zumindest geografisch nicht mehr stimmen.
Müssen wir Hamburg(Stadtgebiet)mit Admin-Level 6 und Neuwerk mit Admin-Level 10 anlegen?
Die beiden bestehende Hamburg Relationen haben einmal Neuwerk und einmal das Naturschutzgebiet eingeschlossen. Beide sind mit Admin Level 4 getagt. Allein diese Tatsache ist unschlüssig.

ludwich

Nahmd,

Tirkon wrote:

Die automatische Berechnung des Ortes, an dem der Name eines Polygons gerendert wird, ist IMHO eine suboptimale Eigenschaft von OSM.

Netzwolf wrote:

Nein. Es ist der richtige Weg.

chris66 wrote:

Kommt drauf an. 😉
Bei Flächen wie Wald, Wüste etc. ist es im Prinzip egal wo der Name steht, da kann man automatisch ausrichten
lassen. Bei Place-Polygonen sollte der Name im Stadtzentrum stehen. Wobei die Lösung mit dem place-Node und diesen
als Admin-Centre dem boundary-Poly zuzuordnen ja auch zufriedenstellend ist.

Nein, kommt nicht drauf an.

Die Frage bezog sich auf den Ort, wo der Name eines Polygons gerendert wird. Und der sollte in jedem Fall aus den bereits genannten Gründen automatisch bestimmt werden.

Ein Ortszentrum ist ein eigenes Feature. Das sollte selbstverständlich in ein Admin-Flächenfeature aufgenommen werden, das aber, aber weil es logisch dazugehört (das definierte Zentrum des Admin-Bereiches ist), und nicht, weil das die definierte Position des Labels werden soll. Denn gerade das Ortszentrum ist meist voller POIs und kleiner Straßen, die Platz für Straßennamen brauchen - da kann es durchaus besser sein, das Label etwas vom Ortszentrum wegzuschieben, natürlich abhängig von der Auflösung/Zoom. Und das ist wiederum die Aufgabe für einen Placement-Algorithmus.

Gruß Wolf

@ Netzwolf

Erst einmal Danke für Deine kritische Auseinandersetzung.

Ich bin davon ausgegangen, dass Multipolynome in der Regel nicht für kleine Objekte eingesetzt werden. Bei meinem Posting bezog sich das Ganze (und das habe ich leider nicht dazu geschrieben) auf administrative Objekte, bei denen ein "place" auch dann existiert, wenn es die zugehörige Grenze dazu als Multipolygon gibt. Dabei hängen an diesem place sehr viele Infos, die auch für die Grenze gleichermaßen gelten.

Und dabei ergeben sich die genannten Probleme - insbesondere dass der Nane zweimal gerendert wird und dass man beim Heranzoomen an die Beschriftung des Flächenobjektes nichts zum Editieren findet. Wenn man hier den place als Member mit der Rolle "label" in die Multipolygon Grenzrelation aufnimmt, könnte das Zweitrendern der Grenze als Flächenobjekt vermieden werden. Und man fände beim Heranzoomen einen Punkt zum Editieren. In diesem Falle ist das Rendern am Ort des Place nicht meine Erfindung, sondern existiert schon.

Tag,

das Problem mit doppelten Tags liegt nicht erst bei den Renderern, sondern schon beim Einspielen der Datenbank. Die meisten von uns verwenden osm2pgsql. Und das hat die Eigenart, dass es Multipolygone in einzelne Polygone auflöst, die lediglich anhand ihrer Id noch als was zusammengehöriges erkannt werden können. So entstehen dann aus der Relation 2114212 für München zwei Polygone:

=>␣select␣osm_id,tags␣from␣osm_polygon␣where␣osm_id=-2114212;
osm_id␣␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣tags
----------+-----------------------------------------------------------------------------------------
-2114212␣|␣"name"=>"München",␣"place"=>"city",␣"name:ru"=>"Мюнхен",␣"way_area"=>"697671029.217790"
-2114212␣|␣"name"=>"München",␣"place"=>"city",␣"name:ru"=>"Мюнхен",␣"way_area"=>"25271.444000"
(2␣rows)

Und die winzige Exklave ist dann die Stelle, wo z.B. die Radkarte den Ortsnamen hinschreibt.

Bisher hab ich mir immer damit geholfen, dass ich place-polygone ignoriere, wenn in ihrem inneren bereits ein place-node liegt, aber das scheitert bei Exklaven, weil die haben ja nicht den node. Ausserdem war das früher kein ernsthaftes Problem, weil die ganzen grossen place-Multipolygone erst im Laufe des April 2012 entstanden.

Der eigentlich richtigere Ansatz wäre, schon beim Abfragen der Datenbank diese umgewandelten MPs zu erkennen und z.B. den größten davon zum Rendern auszuwählen. Aber da fehlt mir auch noch eine Idee...

Grüße, Max

maxbe wrote:

Der eigentlich richtigere Ansatz wäre, schon beim Abfragen der Datenbank diese umgewandelten MPs zu erkennen und z.B. den größten davon zum Rendern auszuwählen. Aber da fehlt mir auch noch eine Idee...

eventuell so: absteigend nach Flächengröße sortieren und immer nur die erste Fläche nehmen.

Gruss
walter