public_transport=stop_position jest tutaj nieprawidłowe.

Jeżeli rysujesz linię/obszar public_transport=platform (warto dodać highway=platform), to na odpowiednim węźle highway=bus_stop już nie powinno być public_transport=platform. bus=yes jest zbędne na obu obiektach.

bus=yes jest zbędne na obiektach public_transport=platform, highway=bus_stop, highway=platform. Edytor iD niestety niepotrzebnie dodaje ten tag.

Thanks for sharing your opinion. You’re right introducing and maintaining advanced typography at OSM data level, at least regarding invisible characters, is difficult. I think I’ll have to make some preprocessor for OSM files that would tune the names, and use it for making maps; or a QGIS plugin, or something.

Hi! I don’t agree these characters are invalid, they are not here to insert some evil commands to one’s terminal emulator or cause a kernel panic in one’s iPhone.

U+00AD soft hyphen followed by U+2011 non-breaking hyphen is a common pattern in Polish typography that guarantees that when a line break occurs in a word composed of parts separated by hyphens, both parts in both lines keep the hyphen. When there’s no line break, only U+2011 should be normally visible. Example: "Maroko<hyphen><line break><hyphen>Nowiny". JOSM always shows both soft hyphen and non-breaking hyphen, which is not pretty, but aids editing.

U+00A0 no-break space follows one-letter conjunctions to make sure they are not left alone at the end of the line. And there are some other similar uses. Example: "PTTK<nbsp><mdash> Oddział w<nbsp>Rybniku". Many plain text editors render nbsp differently to a regular space.

I agree most OpenStreetMap contributors are not typography experts, but I’m not certain these characters pose issues that warrant their removal. It’s easier to drop them in software, for example, convert all U+00AD + U+2011 pairs, as well as lone U+2010, to plain old U+002D hyphen-minus; than to correctly guess them from such simplified representation.

way/169413727
maxspeed jest zbędne gdy mamy maxspeed:forward i maxspeed:backward.

way/146617997
maxspeed=10 nie pasuje do maxspeed:type=PL:urban

Wydaje się zbędne.

PL:zone20 byłoby dla znaku B-43; jeśli tutaj jest D-40, to raczej PL:living_street.

Wydaje się zbędne.

way/1454375745
Na parkingi jest dedykowany tag:
amenity=parking

Jaką stosujesz definicję unclassified? Moim zdaniem lepiej byłoby podnieść drogi w miejscowościach z residential do unclassified, dałoby to spójną sieć przy założeniu, że unclassified traktujemy jako poziom pomiędzy residential/service a tertiary.

Jeśli jest living street w terenie, to rekomendowałbym highway=living_street, chyba że są jakieś przeciwwskazania. foot=yes jest niepotrzebne, motor_vehicle=yes nie polecam, chyba że uzasadnione oznakowaniem.

FWIW
zone:maxspeed=*

The school is already tagged on this area:
way/1031575190
It shouldn’t be duplicated on the school building object, see:
osm.wiki/One_feature,_one_OSM_element
Please remove name and website from the building.

Unrelated, but consider using JOSM (a Java-based editor), while initially it may be more difficult, it won’t teach you some bad practices of iD (the web editor you made this changeset in).

n?

+1
Poza tym zbędne access i construction.

Jeśli są znane powszechne tekstowe nazwy kolorów w CSS, np. white, to takie bym zalecał.

1. Jeżeli height nie jest dokładne, to bezpieczniej (i jest to dużo popularniejsze) zamiast niego podać building:levels.
2. Zamiast roof:direction=90 preferowałbym roof:orientation=across (chyba że coś tu źle rozumiem).

W name celowo były niełamliwe spacje po jednoliterowych spójnikach, patrz:
https://pl.wikipedia.org/wiki/Sierotka_(typografia)