Hi Georg,

Moved all the replicating tags of the sperrstelle to the relation. Added some wood and made some areas inner where appropriate. The result is that of the stelle now all 4 render, all through the relation qualified as dragon_teeth which only 1 of 4 had as feature. looks great to me now
way/313913181#map=19/46.71549/8.89423

As for the Uni, it's fine as it is.

ciao
Rob

Buildings on pedestrian areas are invisible in Carto Standard unless made inner to the area. Mapped the post office building on St.Peter's square, never wanted to appear. Roofs OTOH show because they are on layer=1 these days.

cheers

Ein anderes beispiel way/510628467

Und andere verwendete tags wie im taginfo https://taginfo.openstreetmap.org/search?q=high_ropes_course

The sky is the limit. :O)))

(In meinem besten Hackensack-Deutsch ;) Ich habe alle Waldrollen entfernt. Jetzt sollte es in Carto Standard mit Bäumen gerendert werden, aber es ist nicht korrekt. Es wäre besser, den Park durch eine Grenze und einen Knoten in der Mitte mit den Informationen zu ersetzen, jetzt ist es eine Art Mapping für den Renderer. Sehe changeset/120093086

'Ignore'? You may, I don't.

After doing an inventory of the wall situation few days ago, I've decided now to park the issue FTM as it requires dedicated time to clean this up, remove all the endlessly and inconsistent information duplication to include name:... language tags etc and post a note to each wall part to only add supplemental info to the relation. As it stands the site relation misses wall parts as well, 5 appear to have the English wikipedia reference most others the Italian and some only the wikidata. There's like 68 'areas' to map. No intend to engage in that endeavour, cleaning up what's there is the first step to take IMO.

I'm sorry if you got that impressions from my words. Past experience, no reaction to a previous Change Set of yours I commented on either, a mapper commenting including a list of the edit sets comments you did not respond to boot it draws a picture.

For your interest, an active list of past comments to your edit sets and your replies is actually public: https://resultmaps.neis-one.org/osm-discussion-comments?uid=224342
Up to you to ignore other mapper observations to your edit sets but it did draw the DWG attention.

Meaningful CS closing comments is important to know what was done which you haven't. Another data point from your contribution statistics page:

OSM Notes: Closed w/ comment 248 (w/o 224)

Can that be right, closing 248 map notes and 224 done so without indicating why the note was dismissed? If right that means 224 messages to other mappers went out telling them their map not was closed without a reason given.

I can't erase past comments made, but we can move forward and do better expecting the courtesy to all in the volunteer community of why what change(s) were made to include indicating if something needs revisiting / why left unfinished.

TTYL

Marc

He replied to me via PM where I copied the comment to as well, see PS, given that JOSM mappers somehow do not get the comment message if raised via the ID Editor interface, at least that is the observed quasi pattern.

NB: The layer=2 on the primary road has unknown purpose. Expecting an alert tomorrow about this with no-bridge or something.

Continued: Add turn lane rules and add directions to stop/giveway spots.

Interesting, so the view is/was to map overlaying lines again and again and again going with the risk not to connect or even overlap areas as was found here where the single wood 'inner' outline went inside the grass zone.

As for rebuilding, In this region I've come across MP's with 2000-4000 members, thousands of nodes single lines, one with even 56000 nodes, which ID Editor today does not seem to allow. Impossible.

Can point to many active mappers that work the way I do, but what I do not do but rarely and see daily is e.g. multiple isolated scrub zones in forest which are then also put in a MP relation so what you get is N rings, all outer in 1 MP, to include scrub pockets that are not even inside the forest. I'd say the admonishing of that user block sample has long been binned or rather, is not widely taken on, certainly by far not taken as working guideline.

I'll try to take the advise though on of not changing the methodology used in an area. Makes sense for those coming after me.

Thanks for sharing.

Hi, moi ancora

You left some unfinished, unconnected with the added cycle path. Not sure what surf=asphalt intersection is meant to do but made it surface. Version 6 it says in the change set with is really strange.

BTW, I'm not tracking you. Osmose is flagging -me- because in the history I once edited an involved element and then makes me forever and ever co owner any new issue involving that object. Of course goes for all mappers. Some clean their list regardless if being the cause or not (moi), some work on their list at times, some never ever do and have 10s of thousands of issues listed to their name.

Anyway see changeset/119963795 . It summarises that 3 things were resolved.

Let me know if there's something not left properly corrected.

ciao ciao

Rereading the wiki, the problem is the ever growing 'inner' being mapped by various, 12 mappers, 13 interpretations. Take a big box with 2 squares inside that float in the centre and the 2 squares share 1 side. Some will draw another line around the 2 squares and tag that as inner. Then a 3rd square enters the fray and shares 1 half side with square 1 and the other half of that side with square 2. Now the forest is inner to 1, 2, no role yet on 3. Then the mapper decides to tag that 3rd square as inner and you got the forest running twice between the square. -TO ME- cutting up the outlines of the square is much simpler. Few if not none will go about and delete the old outline around 1-2 and map a new one around 1-2-3.
The largest issue I have with what the wiki samples is, that if you touch any border running between 2 areas is, you only get told what that border is for on 1 area, not roles and memberships of the borders that are 'below' so to speak. One finds at times 3 lines on top each-other. Does not work for me. 1 border in a multi area multiprocessing structure with all it's roles shown I much prefer. No flagging in Inspector regardless of OSM having the render tolerance or not. If Inspector, Osmose, Keepright etc are wrong then maybe they should be adapted to that OSM tolerance. Classic case, 1 says that the spelling 'side= is correct and the says sides= is correct for 2-3-4 sided totems and billboard. Seems there's no agreement what it has to be.

You're correct, I missed to remove that inner forest role that passed between the grass and scrub. Duly removed. We'll see tonight if OSM Inspector is still highlighting all of these with dark blue i.e. borders used in multiple rings that intersect itself.

Hi,

OSM Inspector flagged your sperrstelle: Simple lines and areas cannot be combined in a multipolygon caused open end warning. I've mapped the lines as areas as well of your sperrstelle to resolve. Better may have been to create a relation instead of an multipolygon.

There are 2 wiki's discussing supplemental tagging that could be appropriate to add: defensive_works defensive_works=* and barrier=tank_trap. barrier=tank_trap. Think Toblerone line is quite fitting to how they look from space. Taginfo shows 58 uses of that value.

ciao

Hi,

I must have been fixing the Wienerwald for the dozenth time in the last month. You, and not only you, need to pay attention to inner and outer roles and where they go. When e.g. scrub and grass share sides, the forest role should not pass in between, the line should be cut and the forest role removed inbetween. Here in fact the scrub is no longer inner anymore since the forest is not 360 degrees surrounding it. There's more of the same problems to the east side forest as well, again scrub and grass sharing a side(s) with each other. The forest outline cant go there, not inner or outer.

Also there was a new line drawn only used by the wald relation, in places it overlays the grass area which caused render issues.

Anyway the corrections are in changeset/119943525

Study the changers please and if not understood, ask, as keeping repairing this wood is not good for anything.

Ciao from the Abruzzos

Hi,

Perché hai tolto il nome 'Largo Sant'Eustachio' e poi l'hai ripristinato come Piazza Sant'Eustachio? Si prega di aggiungere il tag osm.wiki/Tag:source=.... sull'oggetto con la descrizione delle origini.

Ciao,

Buildings removed should be tagged as razed:building and possible have a note added, so other mappers know not to remap or retag. There's also abandoned:xyz and disused:xyz for items no longer there. Then they'll not render but a dotted line will appear in the edit view. See changeset/119903309 as to the what I did.

ciao

Hi,

You mapped a school with the same name as the adjacent building. Suggest you remove the names from the buildings and add it to the schoolgrounds as this will surely be flagged by QA.

Also, somewhere in you changeset changeset/119880291 you mapped a way that crosses another way without connecting them resulting in a warning. Connection is important as else routing will not function. Please fix.

Ciao

Hi,

sorry but your cleanup failed, in the example a forest should not have a outline or inner relation on a scree area when the scree area is not 360 degrees INSIDE the forest. I've removed several duplicate lines and used single line for the correct adjacent forest relations and added a shingle area as inner to the correct forest.

ciao