OpenStreetMap logo OpenStreetMap

Changeset When Comment
177338127 11 days ago

Ahoj. Podľa ortofoto aj podľa fotky z roku 2020 tam je most. Prosim prever a oprav ak treba.

Ak iD editor varuje ze sa krizi ceta a vodny tok, neznamena ze je to automaticky brod.

177909777 13 days ago

Ahoj Peťo.

Vidím, že dosť edituješ landcover a preto ti dávam do pozornosti nástroj na www.freemap.sk, ktorý ti pre zvolenú oblasť "obkreslí" lesy/lúky: https://groups.google.com/g/osm_sk/c/d_6Csbkc5gw/m/5DhuXdsoAgAJ

Editovať potom odporúčam v editore JOSM. Ak niečo, kľudne mi napíš.

177493580 22 days ago

construction=house nie je dobre na celu plochu, lebo to hovori, ze tam stavaju jeden obrovsky dom

177039509 about 1 month ago

Hi, thanks for taking the time to explain the typographic background, I appreciate that.

I fully understand that U+00AD, U+2011 and NBSP are legitimate tools in professional typography and that they are commonly used in Polish texts to control line breaking and avoid single-letter words at line ends. I’m not suggesting these characters are "evil" or security-related in any way.

My concern is more about how OSM name=* is used in practice. It's primarily a data and interchange field, not a typesetting string. Many OSM data consumers (search engines, geocoders, QA tools, renderers, exports) either don't preserve these characters consistently or users cannot easily type them when searching. Invisible or special whitespace/hyphen characters also make manual editing and comparison harder, because strings that look identical are not equal at the data level.

Because of that, keeping typographic line-breaking hints in name=* usually doesn't reliably achieve the intended effect anyway, but it does introduce interoperability and usability issues. For example, users searching with a normal hyphen or space may not get a match, and different tools normalize these characters differently.

For this reason I'm treating U+00AD, U+2011 and NBSP in name=* as presentation-only formatting and normalizing them to a simpler, widely expected form (plain hyphen-minus and regular space, soft hyphen removed). This matches common OSM practice and keeps names easier to search, compare and process across tools.

If there is a case where a special hyphen character is explicitly part of the official written form on signage or in authoritative sources (not just a typographic hint for line breaks), I agree that it should be kept. But for general Polish typographic conventions, I think normalization in name=* is the more practical choice for OSM.

Hope this clarifies my reasoning.

42233794 about 1 month ago

uz netusim 🫣

175592661 2 months ago

Cau Peto. Davaj prosim access=private na tie sukromne bazeny, nech sa neobjavia v turistickych sprievodcoch :-)

153456723 2 months ago

opravene

173909264 3 months ago

I agree that the edit is valid, just unfortunately some renderrers depend on boundary=administrative on border ways. For example https://www.freemap.sk/#map=9/48.764322/22.604240&layers=X

173020458 4 months ago

+source ZBGIS

143499941 5 months ago

Neviemn. Mozno ZBGIS alebo INSPIRE data?

17787444 6 months ago

Hi.

It was a bad decision made long time ago. I am since then putting them on correct position and AFAIK I was reverting such changesets.

145910790 6 months ago

ani cesta? ani diera v plote? ;-)
kludne to prosim oprav podla reality. dakujem👋.

145910790 6 months ago

Vdaka za info. Trochu som to upravil, ale bude nutny prieskum na mieste.

121558897 7 months ago

Please don't do such edits.

16424655 7 months ago

Uz netusim, kludne odstran.

130219619 7 months ago

Hi. Please see osm.wiki/Relation:waterway

166083157 8 months ago

Myslim, ze namiesto image=https://backend.freemap.sk/gallery/pictures/657529/image?width=1110 dat image=https://backend.freemap.sk/gallery/pictures/657529/image

166083157 9 months ago

Ahoj,

Ked pridavas foto na freemap, maz prosim `?width=1110` z URL. Vdaka.

124080822 10 months ago

Feel free to update it in OSM if you have more precise and recent data. Thank you.

97512878 10 months ago

takto to bolo v importovanych datach; treba survey