Фізичні помилки в адресації звичайно існують. І не лише в Чернівцях. Але у цьому конкретному випадку нам також нічого не заважає замість точки поставити полігон, що обмежує магазин в середині самого будинку Кохановського 2.
Навіть в цьому випадку, погодся, полігон більш точно описує два обєкти. Відразу було б видно, де основний будинок, а де магазин, і що у них різні адреси. Чим краща точка чи підпис у яндекса 2,67 особисто мене не дуже зрозуміло. OSM всеодно не дозволяє мапити в 3D і проставляти різну адресацію на різні поверхи. Хоча як варіант можна ввести додатковий тег, який би говорив, що це якась фігня з адресацією і різними поверхами.
блін, в НП багато назв не транслітеровані. Вручну пальці задимляться. Запросити б бота
Ще попадають варіанти коли прізвище назви вулиці транслітероване а з часом ім’я додалось в name, а name:en залишається незмінним.
Якийсь інструмент можна пришити до валідатора?
якщо до кожної адреси так підходити, можна з розуму зійти
моя думка не міняється - адреса на точці має бути еквівалентна адресі на полігоні.
а якщо ми тут говорим про те, що точками мапити невірно - то, швидше за все, це вірна думка, але в більшості випадків у нас нема вибору. вважайте точки недоробленими полігонами, бо щоб з кожної такої точки зробити полігон, потрібно провести досить велике дослідження з обходом будинку, опитуванням мешканців.
Можливо й точніше було б вносити всі дані полігонами, але ніхто цього не робить.
Не маю точної статистики, але думаю що десь 95% існуючих POI задано точками.
Ігноруючи точки з адресами втрачається досить таки багато адресної інформації.
Можна вважати, що точка - це усереднений полігон. Чим вона гірша за полігон в контексті адресації?
Так зараз мова йде не про POI, а адресовані будівлі. Який відсоток з них мають подвійну адресацію через точки? Назву точну цифру сьогодні-завтра, але думається що % мізерний.
Ідея в тому, аби не робити будинок чи частину будинку точкою, нехай точками лишаються тільки POI (адже їх дійсно багацько), які б наслідували адресацію у батьківського полігону адресної ділянки. Давайте, зробимо наступним чином: якщо точкових адрес на територіях з супутниковим покриттям буде не більше 500 будемо вважати це за помилку і переведемо їх в полігональну геометрію, ок?
не знаю, як швидко виділити місця без супутникового покриття, але на Україні точок з addr:housenumber, без tourism, amenity, shop, office, building, leisure в мене получилось більше 6000. В будь-якому випадку, я не знаю, як переводити на полігональну геометрію всі ці точки, і проти поділу їх “наобум”
Это работа не для бота.
Простая транслитерация может быть осуществлена конечной программой, и с этой точки зрения ниличие транслитерации в базе не нужно.
С другой стороны, простая транслитерация зачастую приводит к ошибкам, а наличие ошибок в базе - безусловное зло.
Т.о. автоматическая транслитерация, в зависимости от конкреиного случая может оказаться от совершенно бесполезнной до принципиально вредной.
Пользы от нее даже в самом благоприятном случае получить не удастся.
Пример сложностей при транслитерации:
Красная площадь (Москва) - Reg Square
Красная площадь (Переславль Залесский) - Krasnaya Square
Вообще-то это обычный объем работы для занесения в базу достоверных данных.
И говорить, что “нет выбора”… В общем, если другими способами получить достоверную информацию невозможно, то выбора, действительно, нет: обойти здание со всех сторон, сфотографировать таблички, опросить жителей.
Лично я такую работу проводил. И мне кажется, что если нет желания этим заниматься, то лучше и не мапить. Лучше отсутствие информации, чем дезинформация.
Транслітерація апріорі не може призвести до помилок. Не треба змішувати поняття перекладу і транслітерації, яка покликана правильно озвучити автентичну назву якомога більшою кількістю мов (а не одною, нехай і дуже поширеною). Читаємо дуже актуальну і правильну статтю: Белорусские названия на латинице: более компетентны ученые или «знакомая американка»?.., актуальну не лише для Білорусі.
Вы ошибаетесь:
На территории бывшего СССР (local.osm с gis-lab.info)
1 581 659 адресов для полигонов,
84 342 адресов для точек.
Итого, не 95%, а лишь 5% задано точками, остальные - 95% полигонами.
5%
Собственно, лично я у себя все равно полигоны с адресами превращаю в точки с адресами, так что мне вообще без разницы - точка имеет адрес или полигон. Но это все равно некоторая потеря информации. Другое дело, что для своего приложения я такую потерю считаю оправданной. А для других приложений это может быть не так.
Вот именно.
Транслитерация может и, нередко, приводит к ошибочному значению в поле name:en.
Именно потому, что транслитерация и перевод - разные понятия.
А статья очень интересная. Еще один повод позавидовать белорусам. Хотя сами они и считают, что у них еще далеко не все в порядке, но хоть есть на что опереться на официально-государственном уровне.
IMHO, раз уж тег называется name:en, то и его значение должно быть на английском. То есть так, как бы записал его англичанин “на слух”.
И вроде бы в Украине правила транслитерации так и составлены. Без всяких там диакритических знаков.
Я проводил статистику для объектов типа node, имеющих тег addr:housenumber, и объектов типа way, имеющих тот же тег.
Называть их в дальнейшем “точками” или “POI” - решать не мне.
Абсолютно согласен.
Я имел в виду лишь случай, когда “неверная информация = дезинформация”, и утверждал, что вариант “неполной информации либо ее отсутствия” предпочтительнее варианта “неверной информации”.
Якраз вчора разом з ~Jhellico в приватних повідомленнях обговорювали питання тегування будинків-мультиполігонів.
Я його просив не переносити теги на мультиполігони вказуючи на наступні недоліки тегування зв’язків:
незручність редагування таких даних як в потлачі так і в джосмі(ось хоча б додати такий мультиполігон у street-звязок)
такі дані “погано”(ніяк не) відображаються в потлачі, що вводить новачків в оману і вони додають туди додаткові теги
конвертори під навігатори не розуміють таким чином проадресованих будинків
nominatim(пошук на osm.org) також не знаходить такі адреси
(можливо я десь помиляюсь, поправте якщо так)
Я говорю тільки про будинки(у інших мультиполігонів описаних проблем просто не існує), причому тільки про ті у яких тільки один зовнішній контур(таких переважна більшість, але все ж виключення мабуть існують)
Крім мультиполігонів типу “один outer + один-два inner”, про один з яких писав DimaZ є ще багато мультиполігонів типу “два або більше outer”: http://www.openstreetmap.org/browse/relation/2070208
Такого було багато наімпортовано, але зустрічалися й створені вручну в Хмельницькому і Львові.
Всі такі мультиполігони тільки ускладнюють підтримку цих даних.
Можна обговорити це питання в окремій темі щоб не засмічувати тему про nadoloni.com.
olehz, на nadoloni.com з головної сторінки при кліку на порядковий номер(наприклад #1 для Харкова) відбувається перехід по некоректному посиланню http://nadoloni.com/{$url}
неполная информация != дезинформация.