Aber schon eine Käse wenn eine Fußgängerzone … Gebäude überdeckt…
einerseits findet man so die Probleme eher, und andererseits gibt es ja auch Fußgängerflächen auf Gebäuden
Hier ist es sowieso ein Spezialfall weil kein area=yes getaggt ist, der way aber wohl wegen place=square als Polygon interpretiert wird
Mich wundert hier auch dass der “name” nur italienisch ist, nachdem er in der Vergangenheit auch schon zweisprachig war
Und noch ein Hinweis: multipolygon relationen werden afaik immer noch nicht für das Routing genutzt, d.h. aufpassen dass man beim Fixen kein Loch in den Graphen reißt
Wenn man osm-carto als Werkzeug und Rückmeldung an den Mapper betrachtet, ob das Mapping so passt, dann ist das i.O.
Vor neun Jahren hat DD1GJ daraus bereits ein korrektes MP gemappt. Drei Jahre später hat ein damals neuer user in seinem 13. CS dem Umriss wieder eine Fußgängerzone zugefügt und keiner der nachfolgenden Mapper hats bei weiteren Ergänzungen gemerkt.
Carto ist nur ein Kartenstil… dieser sollte das beste aus die Daten machen und nicht das mapping beeinflussen. Aber kein “Werkzeug und Rückmeldung an den Mapper”… Das verhalten würde sehr viele Multipolygone zu folge haben was… meiner Absicht abzulehnen ist.
Da ist die Frage steht die Kirche auf dem Kirchenplatz oder nicht… oder sagt man nur Außen herum… Aber ich würde sagen die Kirche ist teil des Kirchenplatzes… In sofern ist eigentlich eine Multipolygon falsch…
Hier mach ich das aber ich werde mich nicht hinreisen lassen das wo anders auch nochmal zu fixen… sehe den Fehler bei Carto.
Drei Jahre später hat ein damals neuer user in seinem 13. CS dem Umriss wieder eine Fußgängerzone zugefügt und keiner der nachfolgenden Mapper hats bei weiteren Ergänzungen gemerkt.
weil es beim rendering erst zum Tragen kam als place=square ergänzt wurde, hatte ich oben schon erklärt
Da ist die Frage steht die Kirche auf dem Kirchenplatz oder nicht… oder sagt man nur Außen herum… Aber ich würde sagen die Kirche ist teil des Kirchenplatzes… In sofern ist eigentlich eine Multipolygon falsch…
für place=square ist das multipolygon dann nicht die richtige Stelle (sondern der outer way), für highway=pedestrian dagegen schon
Verkehrswege und Verkehrsflächen als obersten layer zu rendern ist eine bewusste Design-Entscheidung von osm-carto. isn’t a bug, is a feature!
Das ist manchmal nicht schön, aber perfekt für alle ist leider nicht zu haben.
Wenn man betrachtet, dass der Kirchplatz gepflastert ist und man über den Kirchplatz laufen kann, dann ist schwerlich vorstellbar, dass die Kirche auf das pflaster gestellt wurde… Aber ich lasse das als Ansichtssache und Betrachtungsperspektive gelten, dass es für Dich wie ein Fehler aussieht.
Schau mal beim opening_hours Auswertewerkzeug vorbei. Wenn ich das zum Prüfen da rein kopiere bestätigt sich mein erster Verdacht: Es sind die unterschiedlichen Bindestriche…
Ich wüsste keinen Grund, warum diese Halteplätze nicht als bus_stop gemappt werden sollte. Für die weiteren Tags gibt es seit ein paar Wochen einen neuen Key tourism=tours. Das ergäbe dann zusammen
Sollten die ÖPNV Spezialisten gegen die Verwendung von highway=bus_stop für Touristenbushaltestellen sein, könnte man da vermutlich auch drauf verzichten.
Ist vor Ort ein Mast oder ähnliches, der zeigt, dass hier eine (Touristen)Bushaltestelle ist? Oder ist dort “nur” ein Verkehrzeichen Halteverbot ausgenommen Busse zum Aus- und Einsteigen?
Es heißt im wiki deutlich: Use amenity=parking_space to map a single parking space on a parking lot. Mapping parking spaces is an addition, not a replacement, to mapping a whole parking lot with amenity=parking.
Also immer erst parking, dann erst parking _space!
