So ein paar Probleme hatte ich auch bei mir.
Liegt nicht an tourism=attraction, sondern an der Rendering-Reihenfolge. highway=* wird nach building=* gerendert. Gleiches kann man auch in mit Gebäuden gezeichneten Wohngebieten beobachten, die Straße liegt über den Häusern.
Multipolygon funktioniert, weil er dann das Gebäude aus dem highway-Polygon rausschneidet. Eventuell auch mal probieren, ob das ganze auch mit layern funktioniert. Aber ich glaube eher nicht.
Gleiches Phänomen kann man auch bei einem Parkplatz innerhalb eines Gebäudes, oder theoretisch auch bei landuse innerhalb eines Gebäudes beobachten. Die Rendering-Reihenfolge ist schuld.
Osmarender hat eine andere Reihenfolge, deswegen funktioniert das da auch. Wobei (soweit ich das gerade überblicke) highway=* mit area=yes vor building=* vor highway=* ohne area-Tag gerendert wird…
Gut, also haben es alle gesehen und wissen nun, dass es an der Renderreihenfolge liegt. Und dass es dazu auch schon zwei (inhaltsgleiche?) Bugreports gibt. Nämlich die schon oben erwähnten, hier nochmal:
Und eigentlich ist es kein Fehler, sondern nur ungewohnt. Man zeichnet ja selten Häuser auf Straßen (highways). Und in Realität ist das Gebäude ja auch nicht auf die vorher gebaute Fußgängerzone draufgesetzt worden. Also multipolygone verwenden. Das allerdings müsste in JOSM (und den anderen auch) viel einfacher gehen. Also ohne, dass man sich erst mit der Technik (Relationen) befassen muss.
In etwa so: Zwei Flächen markieren und dann dem Programm „sagen“, dass es die eine aus der anderen ausschneiden soll.
Ähnlich einfach sollte es dann in Zukunft auch mit Abbiegebeschränkungen gehen. Einfach einen Knopf dafür, der die Relationen und alles was dahinter steckt automatisch anlegt.
Ich werde mein Antarktis-Experiment jetzt löschen.
PS: Wie lösche ich die Relationen? Der Validator meckert, weil ich alles gelöscht habe, außer den Relationen. Nein, eigentlich meckert er, dass meine multipolygone keinen outer-Teil mehr haben.
PPS: Ah, ich musste bei den Relationen noch den type=multipolygon löschen. Aber jetzt gibt es diese zwei leeren Relationen: 535179 und 535180. Und die kann ich nicht anklicken, also auch nicht löschen. Hmm …
PPPS: Jetzt konnte ich sie doch löschen. Ich musste nur das Relationen-Fenster öffnen (in JOSM das Symbol mit dem Zahnrad) und dann die Fehlermeldung im Validator anklicken (denn auf der Karte angezeigt werden die ja nicht). Dann konnte ich sie im Relationeneditor mit einem Klick auf den Papierkorb löschen. Ziemlich einfach – wenn man das weiß.
Fast so einfach geht es doch eigentlich schon heute bei JOSM:
Die beiden Flächen in JOSM auswählen
Schaltfläche neue Relation
Auswahl erscheint rechts im Relationseditor
Alles nach links übernehmen
Relationstyp eingeben (type=multipolygon)
Den Flächen ihre Rollen (inner/outer) zuweisen.
Bestätigen und FERTIG!
Könnte man noch etwas vereinfachen, wenn die Schaltfläche
“Neue Relation erstellen” Vorlagen für verschiedene Relationstypen hätte.
Insgesamt erleichtert der Relationseditor von JOSM die Arbeit aber schon heute recht deutlich.
Das geht ähnlich einfach, wobei auch da noch etwas mehr Komfort mit einer
passenden Vorlage möglich wäre. Das Denken kann man jedoch nie ausschalten.
Die Einschränkung und ‘from’ / ‘to’ muss immer noch der Benutzer angeben.
Den ‘via’-Knoten kann man automatisch ermitteln.
Der Löschknopf ist soweit unten rechts, dass ich den am Anfang auch übersehen hatte.
Ja, das mit den Relationen ist schon einigermaßen einfach (wenn man alles auswendig weiß, was nach einer Weile schon passieren wird). Aber eigentlich wäre es doch schön, wenn man eine Bus-Route einfach mit einem kleinen Assistenten anlegen kann, der alles für einen ausfüllt. Und genauso auch Abbiege- und andere Beschränkungen.
Man klickt auf das Beschränkungen oder sogar Abbiegebeschränkungen-Symbol (was sich in einem Beschränkungen-Menü befinden könnte) und dann wird man gefragt, wo die Beschränkung hin soll. Von wo nach wo. Erst wenn man alles angeklickt hat (die entsprechenden Wege), dann sagt das Ding: Gut, fertig.
So muss ich immer im Wiki nachsehen, wie das nochmal ging und wie die einzelnen Tags heißen (forward, inner, outer, stop, via, to, bla blub bla, …).
Aber das hat hier eigentlich schon nichts mehr mit dem ursprünglichen Thema zu tun, sondern müsste zu „Wie verbessere ich JOSM und Merkaartor und Potlatch und all die anderen“.
(Potlatch könnte schon mal auf Flash verzichten, das wäre ein guter Anfang. Und dann die Linien und Punkte nicht so dick zeichnen – man kann doch da garnix erkennen).
übrigens… zum server api06.dev.openstreetmap.org…
dies ist effektiv ein testsystem. da kann man in potlatch üben und testen. aber leider werden die sachen, nicht gerendert, die man dort einträgt… also für so tests - wie hier - ist dieser testserver ungeeignet… leider.
wenn man zwar rechts oben Overlays - Daten auswählt, werden die eingezeichneten sachen angezeigt, aber das ist nicht wirklich hilfreich für so tests…
siehe http://api06.dev.openstreetmap.org/?lat=-73.54795&lon=14.16707&zoom=16&layers=B000FTTT
weiss jemand vielleicht einen alternativen testserver, bei dem die eingetragenen sachen dann auch gerendert werden?
Auch mal 'ne Frage: Funktioniert das “Anstupsen” mit /dirty eigentlich auch bei der Cycle Map?
Ich habe hier angefangen, eine neues Radwegenetz einzuzeichnen, also so mit network und route. Und ich wüsste ja zu gerne, ob das jetzt auch funktioniert.
Die OpenCycleMap hat ihren eigenen Update-Rythmus etwa einmal pro Woche.
Es wurde berichtet, dass Donnerstag ein guter Kandidat für das Update ist.
Dabei ist wohl noch ein Tag Bearbeitungszeit einzurechnen.
Könnte also heute oder morgen klappen.
Die andere Frage ist, ob OpenCycleMap überhaupt lokale Netzwerke
darstellt und wie es mit Eltern-Relationen umgeht.
So wie ich das sehe, stellt OpenCycleMap das alles dar. Jedenfalls werden Netzwerke hier in der Nachbarschaft dargestellt, auch solche, die als lokale Netzwerke gekennzeichnet sind: network=lcn und entsprechend mit route usw.
Aber warten wir einfach noch mal ein paar Tage ab.
