No ale skoro tak jest napisane na tablicy, to czemu powinniśmy na mapie mieć co innego? Chcemy po polsku? Jest w name:pl…
Nazwą miejscowości nie jest Kosorowice/Kossorowitz tylko Kosorowice po polsku i Kossorowitz w języku mniejszości. Chyba ground truth nie działa tak, że przepisujemy to co na znaku bez analizy co oznacza, bo wtedy mielibyśmy na przykład name=Nowe Miasto Gmina monitorowana
Tylko, że to są zupełnie dwa różne znaki. Na znaku E-17a jest nazwa (nazwy) miejscowości, a znak “miasto monitorowane” tak właściwie nawet nie jest znakiem drogowym. To jest trochę porównywanie gruszek z jabłkami.
Znaczy, ja się upierać nie będę, bo ani myślę tu jakiejś rewolucji zaczynać.
Tym niemniej w Belgii tak zrobili, nazwy ulic w Brukseli też są dwujęzyczne zarówno na tabliczkach, jak i w OSM, więc poza zaszłością nie widzę problemu, żeby i u nas zrobić podobnie.
Również nie zamierzam się spinać, ale (nie sprawdzałem co jest np w Teryt) skoro ‘małpujemy’ generalnie wszystko wg baz urzędowych, to niech tak już zostanie. To że tak zrobili w Belgii - a niech mają - jak im te dłuuuuugie napisy nie przeszkadzają w czytaniu mapy. W mojej ocenie to kiepski pomysł - głównie ze względów praktycznych (wizualnych). Chociażby przykład marafa. Dwuczłonowa nazwa w Dwóch językach jest w stanie schować całą miejscowość pod sobą - kiepsko to wygląda.
Belgia to trochę inny przypadek, bo oni mają trzy języki urzędowe, więc nie da się wybrać “lepszej” nazwy. W Polsce jest jeden język urzędowy, więc te obcojęzyczne człony są traktowane nieco jak “dodatek” - w wielu przypadkach w ogóle nie używany. No i pojawiają się dodatkowe problemy, bo nazwy miejscowości to nie jedyne dwujęzyczne nazwy jakie istnieją. Co z nazwami ulic? Jastarnia używa dwujęzyczne nazwy ulic, więc trzeba by zmienić dać tam nazwy ulic typu “Antoniego Abrahama/Antoniego Ôbrama”?
Nazwy w językach mniejszości istnieją prawnie w Polsce dopiero od 10-12 lat, są słabo utrwalone w świadomości Polaków (poza regionami z tymi miejscowościami), a w OSM nie wprowadziliśmy notacji jak w Brukseli na samym początku osm w Polsce.
Cała sytuacja jest nieporównywalna z Brukselą, a na zmiany jest za późno. Zbyt dużo zamieszania w stosunku do zysku-bo to są wszak małe miejscowości, na ogół wsie, i jest ich raptem kilkaset.
Jeśli ktoś chce mieć te nazwy widoczne na mapie to wystarczy renderować name razem z alt_name - to rozwiąże też problem nazw obocznych z PRNG. A te występują nie tylko dla niektórych miejscowości lub ich części, ale także dla rzek, szczytów górskich itp.
W Brukseli dokładnie tak robią.
Nie rozumiem skąd pochodzi parcie na umieszczanie dwóch lub więcej nazw akurat w podstawowym name skoro mamy do tego odpowiednie tagi, a Belgia jest federacją z podziałami zarówno na regiony (geograficznie) jak i wspólnoty językowe z własnymi władzami i to wszystko na obszarze mniejszym od mazowieckiego. Polska jest silnie unitarna i kopiowanie 1:1 rozwiązań z takich państw jak Belgia czy Niemcy nie ma według mnie podstaw, bo jesteśmy inaczej zorganizowani i, mimo wszystko, bardziej jednolici.
Nie do końca, chciałem po prostu pokazać, że obecność dwóch nazw na jednym znaku nie oznacza nagle, że jedna i druga łączą się w name. Musimy się zastanowić czym są i co tam robią, bo to są dwie nazwy jednej miejscowości, a nie jedna nazwa złożona z dwóch członów.
Sprawdziłem status tych nazw w PRNG.
Polska nazwa jest nazwą główną i oficjalną, a nazwa w języku mniejszości ma ststus “dodatkowej”. Nazwy dwujęzyczne (łączone) nie występują w bazie TERYT-u, ani w gminnych SIP-ach i innych danych oficjalnych.
Mamy mniejszości? Mamy.
Te mniejszości chcą mieć dwujęzyczne nazwy i starają się je wszędzie umieścić? Chcą i starają się.
No to tylko kwestią czasu jest pojawienie się parcia i tutaj.
I niech te nazwy będą wpisane dla każdej miejscowości, ale tam, gdzie jest to zgodne z logiką budowy bazy danych, a wstawianie dwóch nazw do pola na jedną nazwę takie nie jest.
A co właściwie jest sprzeczne z logiką budowy bazy danych w układzie:
name=<to, co miejscowość ma tablicach> (patrz: ground truth);
name:pl=;
name:xx=<nazwa w języku xx> ?
Przy czym czepiam się tu wyłącznie argumentu, nadal nie zamierzam przeprowadzać żadnej rewolucji w tagowaniu takich miejscowości.
Ani nazwa tagu, ani dokumentacja na wiki, ani edytory nie sugerują, by tag name nadawał się do umieszczania więcej niż jednej nazwy. Określa się ją po prostu jako “nazwę” (l. pojedyncza) albo nazwę najpowszechniej występującą. Zgodnie z ustawą i intuicją, gdy miejscowość uzyskuje uznaną przez Państwo nazwę w języku mniejszości, to mowa o drugiej nazwie - dodatkowej, a nie jej zmianie, bo nazwa polska i podstawowa się nie zmienia, zatem jeżeli wpisujemy do name XXX/YYY czy XXX - YYY, to nie wpisujemy tam nazwy miejscowości tylko dwie nazwy lub więcej, a to jest niezgodne ze wspomnianymi przeze mnie źródłami i nie możemy liczyć, że każda osoba chcąca edytować OSM czy korzystać ze źródeł danych dotrze do tej dyskusji i zrozumie jak ma wpisywać te dane podczas gdy praktyka i wspomniane edytory czy wiki sugerują co innego.
Nawet jeżeli by można było hipotetycznie zamienić wszystkie nazwy na nowy standard, to pozostajemy z koniecznością ustalenia kolejności wpisywania nazw, znaku pomiędzy nimi i to już otwiera furtkę do nowej kategorii błędów edycyjnych. Tracimy informację o nazwie najbardziej powszechnej, która może być wykorzystywana przy wyszukiwaniu miejscowości, do wyświetlania krótkiej nazwy itp. Oczywiście można ustalić, że to co do tej pory było w name teraz będzie pierwsze, tylko w takim razie po co ta cała zmiana? Nie zyskujemy nowych informacji, bo nazwy w innych językach można wpisać i wyświetlać już teraz, a potencjalnie komplikujemy życie wielu konsumentom danych.
W sumie to chyba jedyny argument, który do mnie trafia. Wiki można zmienić, edytory się dopasują do wiki, krótką nazwę i tak definiuje się osobno, wyszukiwarki poradziłyby sobie i bez wprowadzania zmian do obecnych mechanizmów.
Natomiast owszem, zyskujemy nową informację, a mianowicie nazwę taką, jaka jest na tablicy. Oczywiście, można też wprowadzić dodatkowy tag, który by właśnie to opisywał…
Wprowadzenie tagu określającego języki, w których miejscowość ma urzędowo uznaną nazwę nie wprowadziłoby chaosu w istniejących danych, a dodałoby dodatkową warstwę, dzięki której można by odróżnić name:de dla Warszawy od takiego dla miejscowości z zachodniej Polski gdzie jest to nazwa z tablicy i oficjalnie uznana za dodatkową.
To może szerzej skorzystać z już istniejących tagów jak loc_name lub reg_name ?
Nigdy nie przyjęliśmy takiej zasady, że nazwy miejscowości w osm są takie, jak na tablicach wjazdowych.
Zdarzały się miejscowości, które stosowały inną nazwę niż w TERYT - i w OSM używaliśmy wtedy właśnie nazwy lokalnej. Ale tam była spójność - nazwy była nie tylko na tablicach, ale używana powszechnie, nawet w dokumentach. To była słuszna praktyka-część z tych miejscowości później zmieniła oficjalnie nazwę na lokalną wersję.
Tutaj jednak używane są dwie nazwy i nie można łatwo stwierdzić, która jest powszechnie używana - trzeba pamięać, że to jednak są nazwy mniejszości.
Nb. w polskim osm można spotkać sporadycznie nazwy dwujęzyczne, np. polsko-niemieckie (https://www.openstreetmap.org/#map=10/54.0912/14.6166), polsko-czeskie lub polsko-słowackie (szczyty górskie). Nie dotyczy to jednak miejscowości.
No ale tu chodzi o oznaczenie, co jest na tablicach. O ile w ogóle byśmy uznali, że taka informacja jest nam niezbędna, to lepiej chyba stworzyć do tego nowy tag, niż używać istniejących tagów wymyślonych w innym celu i potem zgadywać, co autor miał na myśli.
To wszystko prawda i w ogóle dzięki, ale o ile to są argumenty za niewprowadzaniem zmiany, to jednak zupełnie nie odpowiadają na moje pytanie. Gdybym się zaparł żeby koniecznie jakoś oznaczać, co jest na tablicach, to najlepszym rozwiązaniem byłby chyba nowy tag.
Natomiast pomysły, żeby wstawiać dwujęzyczną nazwę w name=* będę wracać, skoro mniejszości są na tyle zdeterminowane, że wywalczyły dwujęzyczne nazwy na tablicach, to i tu będą do tego dążyć i prędzej czy później będziemy musieli jakieś rozwiązanie przyjąć.
My już rozwiązanie mamy, więc wszlkie takie pomysły będą podpadać pod tagowanie pod render.