Mag ja sein, dass die Renderer damit umgehen können. Aber da wir ja bekanntlich nicht für die mappen, ist das ja auch egal, denn eigentlich geht es darum, richtig zu mappen. Und da machen manche Kombinationen eben Sinn und andere nicht.
Das ist wirklich die einzig brauchbare Heuristik, wenn dem Renderer nichts anderes als raten uebrig bleibt.
Und das ist sicherlich das, was wir tun sollten.
Flaechen muessen in der Datenbank uebereinander liegen, wenn sich in der Schnittmenge der Flaechen auch BEIDE Eigenschaften gueltig sind. Z.B. eine Spielplatzflaeche ueberdeckt sich mit einer Wohngebietsflaeche => dort ist sowohl Spielplatz als auch Wohngebiet.
Verschachtelte Flaechen muessen per multipolygon-Relation umeinander gelegt werden, wenn in der Schnittmenge der Flaechen NUR die Eigenschaft der inneren Flaeche gueltig ist. Z.B. muss eine Seeflaeche per Multipolygon aus der umgebenden Waldflaeche ausgeschnitten werden => dort ist nur See und kein Wald.
Gruss
Torsten
Renderer sind eh schon zu langsam. Selbst der OSM Server schafft es manchmal nicht, Tiles on the Fly zu rendern. Wenn die jetzt auch noch tile-übergreifende Flächenberechnungen für teilweise riesige Flächen machen müssen, wird die Sache noch viel langsamer.
Aber witzig ist das schon. Vor etwa einem Jahr war ich genau Deiner Meinung und habe mich ganz ähnlich hier verhalten. Aber wenn man es mal raus hat, sind Multipolygone genauso einfach wie ein Way…selbst Wiese im Wald in Residential Area ist dann kein Problem. Und mit der Zeit merkt man, wie wichtig richtige Flächeneigenschaften sind
Ich freue mich schon darauf, deine Ausbildung abzuschliessen. Schon bald nennst auch du mich “Meister”.
Neulich wars noch Führer. Helfe mal mit Grenzen in DE zu korrigieren…siehe “Grenzspezialist gesucht” Thread. Das dürfte ja nicht an Deiner Ehre kratzen
Detailmapping ist etwas, was mich sehr interessiert, da man da viel mit machen kann. Ein paar Fragen bleiben mir.
-
Wenn ich jede Fahrspur an der Ampel einzeln Tagge, müsste ich dann nicht die “Straße” also den “Geteerten Bereich” auch noch irgendwie erfassen? Oder wird hier gesagt “Die Straßen sind so dicht beieinander, das macht nichts”.
-
Ab wann trenne ich die Spuren? Ich würde für mich sagen, erst ab der durchgezogenen Linie. Grund: Vorher darf ich zwischen allen Spuren frei wählen, ab der Durchgezogenen Linie ist das Wechseln verboten.
-
Fehlen in diesem Beispiel nicht dutzende von Restrictions, die an fast allen Kreuzungspunkten ein only_straigth_on beinhalten? Denn aktuell erlaubt das Routing hier ja das Kreuz-und-Quer fahren.
Erforsche deine Gefühle… du weißt das es wahr ist! Ich bin nicht dein Vater!
darüber zu diksutieren ist müßig. Stand der Technik ist dass es “Fahrspuren” in dem Sinne nicht gibt und man sie nur einzeichnet, wenn auch eine räumliche Trennung z.B. in Form einer bereits vor der Kreuzung abbiegenden Rechtsknicks verläuft. Bei der Kreuzung wie er sie eingezeichnet hat versagt jedes Navi (selbst wenn man die Restrictions richtig einzeichnet, wird man seltsame Anweisungen erhalten). Er hat aus einer stinknormalen Kreuzung bis auf die Rechtsabbiegespuren ein Ding gemacht wo jedes Navi versagen wird. Ein sehr abschreckendes Beispiel.
OK, das mit den langsamen Renderern weiß ich aus eigener Erfahrung 
Ich hatte auch nicht die Absicht, hier wieder eine Diskussion über die MP’s allgemein oder deren Sinn loszutreten. Mich treibt hier nur die Befürchtung, dass durch Detailmapping die Zahl der MP’s samt der damit verbundenen Fehleranfälligkeit aus (unbedarften) Änderungen und die daraus resultierende Korrekturnotwendigkeit erheblich zunimmt. Deshalb meine Überlegung, wie und wann MP’s vermeidbar sein könnten.
Noch mal kurz zu meinem Vorschlag oben:
Wenn mich meine kargen Programmierkenntnisse nicht täuschen, müsste doch eine if-than-else-Routine (für edwin: wenn-dann-sonst) reichen, um die darstellende kleinere Fläche identifizieren zu können, wenn nicht schon durch eine andere Regel klar ist, was als oberstes darzustellen ist . Ich denke, Tools wie OSM-Inspector oder keepright müssen noch ganz andere logische Abfragen bewältigen und kommen durch die Datenmengen.
Und ist es nicht so, dass die größeren Datenmengen die Geschwindigkeit der Renderer negativ beeinflussen, was wiederum gegen vermeidbares Detailmapping und die daraus resultierenden überflüssigen Datenberge spricht?
Edit:
Was haltet ihr eigentlich hiervon:
http://www.openstreetmap.org/browse/way/84506439
scrub auf layer -2 und komplett über andere ways/tracks geführt ???
Bin durch gerade OSM-Inspector drauf gestoßen:
http://tools.geofabrik.de/osmi/?view=geometry&lon=7.82380&lat=48.33521&zoom=12
OSM Inspector meldet dort “self_intersection_ways”, da einige Wege für “natural=scrub” sich selbst schneiden => Fehler beseitigen.
“natural=scrub” mit “layer=-2” ist auch falsch:
http://wiki.openstreetmap.org/wiki/DE:Key:layer
Gruß,
Mondschein
Die Tatsache ist richtig, die Begründung aber falsch. layer beschreibt die Lage der Objekte zueinander, wobei layer=0 die Erdoberfläche beschreibt und nicht eingetragen wird. Primär befindet sich landuse auf der Erdoberfläche, weshalb man normalerweise kein Layer taggt.
Sooo, kompliziert sind MPs auch nicht. Du gibst an, was ist die Aussenbegrenzung, was die Innenbegrenzung und fertig.
Verwirrend sind nur die verschiedenen Taggingmöglichkeiten (Tags an Relation und/oder an Aussenlinie).
Und wenn jeder Acker einzeln gemappt wird, werden auch weniger MPs benötigt, als wenn man ein Gebiet
großflächig braun färbt und jeden Wald/Residential/etc. per MP ausstanzt.
Dann nehmen wir uns doch mal zwei Beispiele im schwarzen Walde:
http://www.openstreetmap.org/browse/way/23911542
und nebenan:
http://www.openstreetmap.org/browse/way/23911539
Beides inner als Wiese im Wald. Fleißige Bing-Maler habe Details zugefügt. Mapnik zeigt es ziemlich richtig. Wenn ich da anfange, habe ich den Rest meines Lebens zu tun, um regelgerechte MP’ zu stricken.
ich verstehe nicht ganz, wo das Problem ist. Das ist eine Sache von wenigen Minuten, wenn überhaupt
Der OSM tile Server sollte nun nach einem Hardware update wieder deutlich besser hinterher kommen. Es wird derzeit noch ein wenig daran gebastelt und getunt, so dass es in naechster Zeit vielleicht gelegentlich noch zu ein paar Stoerungen kommen kann, aber ansonsten sind updates hoffentlich wieder schnell zu sehen.
sollte. Ich habe heute Mittag Straßennamen hochgeladen. Die sind immernoch nicht sichtbar. Auch mit./dirty passiert nichts
Klar, beim momentanen Status, bis dann wieder einer was dazu malt. Und das sind nur zwei von wasweißichwievielen. Ich habe sinnvolleres zu tun, als sowas aufzuräumen…
Für mich ist die überwiegende Nutzung gemäß Wiki das maßgebliche. Da kann ein kleiner Acker innerhalb einer großen Wiesenfläche m.E. ruhig unter den Tisch fallen.
Wenn ich dann noch daran denke, wie sowas mit den Standards der simple features vereinbar ist… (,die ich mir übrigens sehnlichst wünsche, da ich nicht zu den Fraktionen “hier kann jeder machen was er will” und “Renderer sind mir sch…egal” gehöre)
Edit:
z.B. das hier:
http://forum.openstreetmap.org/viewtopic.php?pid=162804#p162804
stärkt mich in meiner Meinung 
Nun bleibt mal aufm Teppich. Mein größtes MP, das ich aber vorm hochladen geteilt habe, hatte ca. 65.000 Nodes und über 300 Ways. Das ging auch. Und niemand verlangt von Dir, dass Du das aufräumst. Wenn Du das nicht willst, lass es einfach und tue “sinnvolleres”
Bin wieder unten
Kannst du uns hier auch verraten, ob dein Riesen-MP dauerhaft gehalten hat?
Mir geht es darum, wie man die Erfassung vereinfachen kann, damit sie trotz zunehmender Detaillierung weniger fehleranfällig, besser für Renderer verwertbar, und für den Gelegenheitsmapper keine Spaßbremse ist.
Immerhin geht es hier um die Nachteile des Detailmappings (und seinen Folgen, zu denen m.E. auch die MP-Inflation gehört).
Ah, kurz nachdem ich das geschrieben habe, haben sich die tile admins entschieden alle tiles komplett neu zu rendern anstelle von nur die die sich geaendert haben.
Der letzte komplette Import (und damit komplette neu rendering) wurde vor glaube ich fast einem Jahr durchgefuehrt. Seit dem haben sich sowohl die Mapnik Software geaendert als auch das Stylesheet, sodas es zu inkonsistenzen im Rendering im laufe der Zeit kommen kann. Mit einem kompletten neu rendering sollten diese nun beseitigt werden.
Allerdings erzeugt das komplette Neurendering natuerlich eine erhebliche mehr Last. Da der Server nun aber deutlich schneller ist, kommt er erstaunlich gut voran, sodas wohl geschaetzt irgendwann Morgen er soweit durch ist das normale rendering requests wieder gut abgearbeitet werden.