I agree. The absence of street numbers along way/109138283 would just confirm the removal of its name due, probably, to its privatization.

I believe it is due to its privatization. However, there are several WebGIS - Geoplan, TuttoCittà, TomTom, Apple Maps - that keep calling way/109138283 "Via Moldava".

I have better understood the placement of buildings on the ground and have, consequently, removed the "level" tags. The Cantina buildings are almost entirely on the same ground level as the east entrance, while the northern driveway surface (way/1023471089) is below the embankment on which almost all buildings rest. I had added the "level" tags with the intention of isolating the access of the internal walkable area from the northern driveway surface which are, in fact, on two different levels. I would've put "level=-1" on way/1023471089, but I think that barrier=wall between the two areas might serve the purpose better.

In doubt, I try to inspect the area via iD so as to be able to better check the consistency of my data. It's not easy to find the right tags, in particular those that manage to give a certain area a certain graphic representation. I noticed that "landuse" (and probably "landcover" as well) renders more often on the map than "surface". Is it because "surface" is more suitable for use on paths than for areas/surfaces? Not surprisingly I notice that the highway-tagged areas are represented (almost) all in the same way and that they don't allow to distinguish their surface type in a visual way. Maybe I'm wrong or maybe I'm right, better ask the question now so as not to ask it later.

I think combining "highway" and "building" tags in way/1023471088 was not a good idea. I replaced building=roof with covered=yes and now the errors seem to have disappeared.
However I don't know how else I could've represented all these areas in a meaningful way if I had left them disconnected or left a space between each of them. They must necessarily have common nodes. If, as you say, I cut the edges of a building, wouldn't I transform it from a polygon to an open line? Even in a multipolygon relationship such a change would result.

Indeed, turn restrictions at intersections are placebo when intersections concern only one-way streets. And if even some of the city traffic defies the one-way rule, well, a triple dose of OSM would do them and the community a lot of good. It makes me think how much patience the train drivers must have when traveling the Rome-Pescara railway. In Francavilla al Mare the situation is quite the same, but here (in this situation) the individuals are not as qualified, so nothing new.
The same happens on some exit ramps of Asse Attrezzato (RA12) too, despite the large no-entry signs with "ALT" written on a fluorescent yellow background with even sinister results. Unfortunately the difference between a proper Japanese driver and a kamikaze can sometimes be misunderstood.

Kanpai

i hadn't double checked. the road is so fragmented. i was sure i had taken all the pieces. thanks

removed as per changeset/112802390. readded with changeset/112796829.

That's why I added relation/13349219. The motor_vehicle OSRM route calculation behaves exactly as you said. I'll try with restriction=no_u_turn (changeset/112799207) just to see if anything changes. Otherwise I'll remove it in accordance with the pre-existing signs. Respects

My bad. I deleted relation/11874366 because i thought that the other pre-existing relationships could do without it. I wanted to obtain a route that doesn't necessarily have to pass through the hairpin bend when this maneuver is not imposed by the actual signs, in particular coming from Rapino to Pennapiedimonte and vice versa. I've sharpened my eyes and self-learned to edit (and eventually enrich) these relationships.
I saw that you already corrected the direction in relations 11874365 and 11874364 as per changeset/112741546 so, in place of the previously deleted relation/11874366, i just added 2 new relations in node/1027911370 for both Via Occidentale (way/869906316) and Strada Statale 263 di Val di Foro e di Bocca di Valle (way/869906318) with changeset/112764065, in order to legitimately restore restriction=only_straight_on where needed on this junction. It should now work as expected 🙂

please check note/2881011: note/2881011