SekeRob's Comments
Changeset | When | Comment |
---|---|---|
125215327 | over 2 years ago | Hi Hope you know rhe solution to this 1 way dead end street problem. Either its dead end and oneway is wrong and needs a noexit on the last node or what i suspect the way does connect to Tartini. |
129567058 | over 2 years ago | Hi, Please be aware that schoolgrounds, sports complexes, parks, farmland, basically all non residential areas inside residential zones don't need to be tagged with inner roles. They render 'over' ciao |
129530086 | over 2 years ago | Found them, you moved them to the highway itself. 👍 |
129530086 | over 2 years ago | Hi, Where are the sidewalks now... went for a hike? |
129527815 | over 2 years ago | The results are in "pinging @Joxit - what was outcome of #2205 (comment) ? (pinging again because two years passed, let me know if I should ping less)" Topic to bin. |
129527815 | over 2 years ago | Initiated GitHub bug report. |
129527815 | over 2 years ago | If you put the maxheight=11.5 on the outline the result in 3D is the whole thing renders with that height. You wont see the elevated element. Height=0 makes sure the elements each render correctly (not documented but seen being used by other mappers after researching the vexing issue and it sure resolved the 1 single box 3D appearance). OSM assumes 3 meters per building level, where the height=* overrides the defaults. The outline should in fact have building:levels=4 too. The name (Municipio Tollo) on the 'type' outline is to make it recognisable in editing when picking relations, it does not render anywhere. What renders is "Municipio di Tollo". buildingpart obsolete is new to me. Anyway, the quick check is StreetComplete (well 'quick' is it updates every few days to a week). It rendered exactly as intended and reality. It's my routine check if all is well with multipart buildings. |
129514641 | over 2 years ago | I'm fine as it is now to include "These areas may overlap each other" |
129432960 | over 2 years ago | OK, so I see in turbo overpass https://dev.overpass-api.de/achavi/?changeset=129432960&relations=true that the grassland outline was removed for a large part. This makes the basin as now inner related to nothing, so I'll go ahead and delete that role, since it causes a red flag on the remaining grassland to north and west. Come time you rebuild the landcover a role can be assigned again as appropriate. TTYL |
129527815 | over 2 years ago | It's perfectly fine as it was bar the building:part=yes of course, not civic as that's a repetition of what's tagged on the main building. |
129514641 | over 2 years ago | Check in StreetComplete right now and see if the northern elevated part looks higher or not, Just happen to know a thing or 2 about the mechanisms. And once more, a top adage in QA... write what you do and do what you write. Yes, the building= tags needed to be changed to building:part on the elements. |
129514641 | over 2 years ago | Oh and from your wiki "Use building:part=yes for parts of the building which only have different attributes (building:levels=* and height=*)" i.e. all the parts are =yes and the main body is building=civic. I'm restoring the relation in proper. |
129514641 | over 2 years ago | Please restrict yourself to what you write in the comment... "fix tag..." . Do more, write it, dont leave people guessing and Nobody asked you to change the parts geometry and layering which was fine in 3D rendering. |
129514641 | over 2 years ago | Hi, Why did you delete the building relation? |
129432960 | over 2 years ago | Hi Astra This little basin is tagged with an inner role to grassland far away: osm.org/way/120595395/history But, the actual grassland around the basin that shows in 2km zoom i.e. was there before last Friday when 2km and greater zoom out updates, has disappeared in 1km and greater zoom. There's also a few warnings on the CS about highway-waterway crossing (see CS summary) Anyway you know surely where the fix(es) need to be applied ciao from the Abruzzi |
129478533 | over 2 years ago | And another problem bit the dust.... cathedral now rendering in proper hue. |
115979484 | over 2 years ago | If there is a single node on a crossing as a sum of all individual traffic signals then it's appropriate to use the all directions tag. I prefer mapping the pedestrian and various traffic signals per street and crossings also because of the noted 1 way streets that wont have a signal, bar that for pedestrians.
BTW see now the 'Ponte Ognissanti' name on the table crossing node. First time I see crossing nodes having a name. ciao |
115979484 | over 2 years ago | BTW, countless people forget the direction tag on signals, stops/yield, traffic signs in general. |
115979484 | over 2 years ago | direction=both refers to the traffic_signals. The correct for that is actually traffic_signals:direction, just to keep it simple ;O))) https://taginfo.openstreetmap.org/keys/traffic_signals:direction Sometimes I actually enter the degrees exact, with a crossing that have 1 or more one ways joining. Then Osmose/OSMI gives a false warning of 'may need traffic_signals:direction'. Hit ignore button. ciao |
115985464 | over 2 years ago | Errata: Something to know: If there's a conflict of naming for instance with a Toponomastica, the wiki is clear: Name signs on road supersede, and apparently this was recently reconfirmed over at Italian Telegram where someone went about changing long street names to the short Via Cavour, where they were before the full name of the count. cheers |