On Wed, Aug 07, 2013 at 07:45:50PM +0200, Tobias wrote:
Es sollten immer place nodes da sein. Und die Bevölkerungszahl kann man dranhaengen - dann kann man ggfs ein rendering darüber steuern.
Dann darf jeder Einwohner aber nur einmal gezählt werden oder man markiert, wann eine Zahl schon in eine andere eingegangen ist (z.B. mittels place=suburb). Oder holt sich die Zahlen über die Grenzen.
Das ist ja quatsch - Denn es geht ja um relative wichtigkeit der places untereinander. Aber wie eben dargestellt ist die Einwohnerzahl ein schlechter wert. Es muss immer die Umgebung/Lage mit einbezogen werden.
https://github.com/gravitystorm/openstreetmap-carto/blob/master/placenames.m...
Das ist der OSM Style auf osm.org - Hier wird die Schriftgröße eines places über den place tag gesteuert.
Kuhl. Der Style zeigt ja auch noch einmal, wie massiv die Mapper Mapnik folgen.
Ich sehe das andersrum. Mapnik hat das genutzt was da war um eine halbwegs vernuenftige Karte zu produzieren. Das ist ein geschlossener Regelkreis. Mapper mappen das was die Datenkonsumenten wie Mapnik/Nominatim/MapOSMatic/Navit/mkgmap nutzen und die Applikationen Nutzen das was da ist. Ich habe auch erst jetzt angefangen lanes=, turn:lanes= und destination:lanes= zu mappen seit dem ich weis das MapFactor Navigator da draus einen lane assist bastelt.
Es Spräche aber nichts dagegen auch die Einwohnerzahl zu nehmen wenn sie als solches an den place tags haengen würde.
Ein dynamisches Rendering über Einwohnerzahlen könnte bei all den doppelt gezählten Einwohnern nur über die Fläche durch Grenzen funktionieren.
Falsch - Harsewinkel als Gemeinde und Narvik werden aehnlich gross sein. Trotzdem soll Narvik eigentlich viel Prominenter auf die Karte. IMHO geht das nur durch manuelles hinten - was ja auch das setzen des place tags ist. Ueber die Geometrien d.h. flaechen der Gemeinde kann ich fuer einen Geocoder die zugehörigkeiten der Adressen definieren - Aber wo dann das Label fuer die Karte gerendert werden soll hilft mir null. Automatisierte Algorythmen fuer das placement von labels in einer Geometrie werden an 50% der Geometrien mist bauen.
Aber das war jetzt alles Theoretischer Natur - Welches Problem versuchst du denn wirklich zu lösen? Oder stört dich das Chaos eher so aus akademischen Gründen?
Das tieferliegende Problem liegt in Bremen, wo die nächst kleineren Stadtteile nach place=suburb mit place=village getagt sind - was laut Beitragenden vor einiger Zeit unter anderem aus einem Kompromiss entstanden ist, der wegen dem Rendering von Mapnik zustande gekommen ist (welches sich immer noch nicht geändert hat).
Ein Stadtteil von Bremen ist zum Beispiel Findorff, welcher noch administrative Relevanz durch Beiräte hat. Die Ortsteile von Findorff haben jedoch keine direkte politische Relevanz.
Nun ist Findorff selbst als place=suburb getaggt. http://www.openstreetmap.org/browse/node/30349434
Findorff-Bürgerweide hingegen ist als place=village getagt. http://www.openstreetmap.org/browse/node/30349431
Nun steht zur Debatte diese place=village durch place=quarter oder place=neighbourhood zu ersetzen. Jedoch werden diese ja nicht gerendert und sind daher eher unbeliebt bei ein paar anderen Mappern vor Ort.
Es tritt dort auch mehrfach das Problem wie in Hiddenhausen auf, dass ein Ortsteil den gleichen Namen wie ein Gemeinde-/Stadtteil trägt.
Was ist denn das Problem? Geht was im Geocoder von Nominatim nicht? Ist das rendering falsch? Macht mkgmap mist? Bisher scheint das problem eher ein ästetisches der nutzung von tags zu sein. Ja - das mag unschoen sein und man sollte einiges vielleicht klarer definieren aber das wird nur dann geschehen und vor allem wird nur die community mitziehen wenn es ein konkretes Problem gibt. So ist das bei OSM - Es werden Probleme gelöst wenn sie denn da sind und nicht vorher. Flo -- Florian Lohoff f@zz.de