У файлі koatuu-wiki-compare.log видно ті НП, де є розбіжність у назві (я забрав звідти НП без КОАТУУ у Вікіпедії).
У файлі updatecities.log видно НП, які не співпали за координатами зі списками найближчих кандидатів. Але він трошки застарів, я його поновлю зранку, запустив перегенерацію, яка займає приблизно 45 хвилин.
Трошки загальмувався процес, бо зайнятий на роботі. Що ще почав робити, так це імпорт бази з сайту ВР. Скоро буде точніша інформація по індексах та населенню. Ну, і нарешті зрозумліло що всі недоліки походять з VMAP0, базі, якій вже 24 роки.
есть какой-то либо прогресс с импортом данных?
я полагаю что можно сразу добавлять данные, выглядящие корректными
к примеру, взять таблицу с населением (допустим, эту)
сделать поиск по укр-osm файлу узлов с name или name:uk совпадающими с данными таблицы
(если найдётся несколько - пропускаем строку таблицы)
проверить - указано ли в узле население. если указано - пропускаем
если населения нет, добавляем population тег с данными таблицы
Нет, во-первых, происхождение тех данных совершенно неизвестно, во-вторых, они на коммерческом сайте, что намекает. Ну, и наконец, я совершенно не уверен в верности данных, ну и там всего 1000 нп, что составляет около 3% от общего числа.
Теперь по импорту. Сейчас на паузе – занимался ботом, теперь вот маплю домики в Харькове.
Мой подход к задаче (я уже писал тебе в приват):
Сейчас у меня есть 3 больших плоских таблицы: Википедия, КОАТУУ и дамп сайта Верховной Рады. Все данные отпарсены и в виде csv файлов с сопутствующими программами парсинга.
Написан скрипт сравнения координат, указанных в Википедии с тем, что сейчас живёт на ОСМ. Процент попадания весьма велик. Но данных на Википедии особых нет, кроме высоты над уровнем моря и КОАТУУ. Интерес представляет дамп Верховной Рады.
В дампе я имею (то, что представляет интерес): иерархию, население, индекс.
Теперь, на чём я и застопорился, необходимо связать Раду с КОАТУУ. Вариант решения задачи – построить два дерева, у них одниаковая иерархия – по административному делению, и сопоставить.
Мне нужно сесть и сделать. Вот закончу домики на востоке Харькова, возможно сделаю паузу, и напишу код. Если кто-то хочет помочь, пожалуйста, но это должен быть Перл, и программа, не ручками, дабы в будущем можно было безболезненно отслеживать изменения. Альтернатива Перлу – Питон, но тогда нужно будет переписывать скрипты с нуля.
про верность хорошее замечание
именно поэтому нужно взять какую-то базу за образец
(главное - не Википедию :))
и к ней уже вязать данные с других баз
пусть даже часть данных и не привяжется - без разницы
я полагаю что за основу можно взять данные переписи 2001
вот их сайтик: http://www.ukrcensus.gov.ua/rus/
как оттуда по-хорошему вытащить данные я не знаю
но в любом случае можно написать граббер
получатся как минимум рус/укр/англ названия, область и население
Ну я же написал выше, с сайта Верховной Рады. С Википедии я буду брать только высоту над уровнем моря, которая в свою очередь, взята с сайта украинского гидрометцентра. Раз лень поискать на форуме про ВР, вот пример. Там есть и население. и индекс, и административное деление.
По поводу сайта переписи. Особо не искал, можешь объяснить, как увидеть на экране название какого-нибудь населенного пункта на трёх языках?
Не особо подходит – проблема в строчке “інші сільські населені пункти”. Т.е. снова неполное покрытие. Хотя, как будет закончен проект с загрузкой с ВР, можно подумать и про эти данные. Ценность тут представляет перевод с украинского на русский. Население есть на ВР, английский получается из украинского.
Після заверешення проекту по вивантаженню nadoloni.com, поновив роботу над проектом. Також обговорив з Zverik та dezhin. dezhin буде прикручувати свій валідатор. Але обидва говорять про те, що не варто вивантажувати атоматично дані, і що теґ code:koatuu взагалі зайвий. Що скажете? На мою думку це внесе безперечну однозначність і дозволить далі вже підтримувати за допомогую валідаторів.
Пвру днів займався тим, що виправляв КОАТУУ у Вікіпедії. Планую також додати посилання на неї у всіх точках НП.
Тож зараз планується вивантажити наступну інформацію: КОАТУУ, площа, населення, стаття на Вікіпедію, індекс, код телефону, російська назва.
Далі, помітити ті НП, яких було усунено як place=abandoned, або щось подібне, далі розберуся.
На основі даних встановити admin_level, але для цього нам потрібно ще узгодити правила поділення.
До тих НП, назви яких співпадають у рамках одної сільради, додати статусну частину. Частіше за все це село або селище. Приклад: Губник, Гайсинський район, є і село і селище.
То що скажете, вивантажувати, чи тільки будувати валідатор?
Тег потрібен! Не знаю, як вірніше, code:koatuu=* або просто koatuu=. Американці для своєї БД застосовують теги tiger:name_base= або tiger:name_type=, tiger:source= і т.д. В цих тегах міститься інформація про приналежність до районів, джерело імпорту, перевірку достовірності користувачами і багато іншого. Для України можна теж розробити подібну схему.
Підтримую майже всі вищенаведені заходи
Я проти того, щоб перейменовувати (обтяжувати додатковою інформацією) населені пункти: не варто дописувати приналежність до району в назву. Для цього є інші теги. А пошукові машини за ними мають вирізняти однойменні населені пункти. В найгірших випадках назва з районом затулить власне мапу цього селища.
Ні, я мав на увазі у випадку вище писати не район (він той самий), а “Губник село” та “Губник селище”. Район я писав, бо може комусь цікаво буде подивитись. І писати таке лише у випадку повного співпадіння назви у НП, які належать до тої самої сільради. Таких випадків небагато, але є.
Виникла ідея. А що як нам використати дані з сайтів і створити БД по мережевих торговельних закладах, відділеннях пошти, банкоматах і тп? Назви, адреси були б в єдиному, зручному для пошуку форматі. Чи може об’єднувати мережу в relation?!
Я на ті бази постійно задивляюся, але поки не закінчено адресацію у кожному конкретному місті, ними користуватися тяжко. А так, щоб їх зібрати докупи… Вже робилося таке, наприклад, http://gdebankomat.com
А об’єднувати мережу в relation не треба, і навіть взагалі, шкідливо. Причина в тому, що їх обробка накладає серйозне навантаження на БД, тому і в оприділенні англійською пишеться, що це “об’єкти, які поєднані гегорафічно (прилеглі або дотичні)”, і до того ж “Відношення – це не категорії”. Докладніше тут: http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories
Сьогодні планую вивантажити КОАТУУ та населення для 90% НП в Україні. Також там будуть name:ru, name:en та індекси.
У зв’язку з цим з’являється можливість правильно призначити статус НП. Тож постає питання, за якими правилами ми будемо призначати city, town, village та hamlet.
Я пропоную наступне:
100,000 city
10,000-99,999 town
<9,999 village
Від hamlet пропоную взагалі відмовитися на території країни.
Альтернатива – якимось чином використовувати офіційну класифікацію Смт, село, селище. До речі, в нас зараз різницю між цими трьма видами НП ніяк не відображено. Будемо щось робити у цьому напрямку?