Я редактирую этот гадюшник, почти 10 лет, использую данные ОСМ. Общался с теми кто данные использует и в классических гисах и более хитрых. Общался и с людьми из фб и Майкрософт которую. Это не проблема, от слова совсем. Многие кто использует осм, вообще никак не столкнуться с осиротевшими веями или нодами, на 20 тысяч использованных лишь один раз тэгов — тоже всем наплевать. Это не волнует ни крупных игроков ни мелких ни обычных маперов. Вам тоже самое говорят те кто осм использует на Хабре.
То что действительно напрягает комьюнити и вызывает споры, это порой излишне рвение нарисовать абы что, лишь бы побольше для хот. И как использовать импорты и платных редакторов от фб/эпл/МС так чтобы не угробить местные комьюнити. К бд особых притензий нет. Вы съездили бы на любую осмерскую конфу, да сопоставили бы ваш анализ с тем, чем участники проекта реально озабочены.
И отношения я хотел бы перевести в голые контейнеры, ибо этот дурацкий тег role почти всегда пуст.
Вы лично можете занимать свой ум любыми упражнениями. Но вы же не об этом на Хабре пишете, а о том что ОСМ помирает из за структуры данных в базе. Вам просто не нравится текущая структура данных, и вы пытаетесь найти вескую причину чтобы все переписать.
Вот Вы — что предлагаете делать с теми 300К веев, которые ни описаний ни даже ссылок не имеют?
Немедленно — ничего. Если кому-то прям сильно мешает, ну починит (если например просто забыли навесить теги) или удалить. Зачем бежать расчёсывать там где не чесалось.
Помечать ворнингами веи, участников отношений, без тегов — а на что вы предлагаете их исправлять? Только пожалуйста в текущей модели данных.
Я вас весьма внимательно прочитал. Не смотря что вы используете свой язык и терминологию не свойственные ни для осм, ни для классических гисов.
объект без описания — это ненормально, это ошибка
Это претит вашему чувству прекрасного, такой вей (без тегов но являющийся частью отношения) не выражает объект реального мира сам по себе, это, в таких случаях делает отношение.
Так, значит, не в шахматы а в покер, не миллион, а 300 тысяч, не выйграл, а проиграл. То есть, вы нашли несколько миллионов веев без тегов, записали их в ту же категорию ошибок, что и осеротевшие веи, и предлагаете автоматом это пофиксить. Удачного вам обсуждения ваших инициатив в osm-dev рассылке.
Дак api 0.6 это как раз про модель данных, это появление отношений. Старик Оккам говорил не плодить сущностей сверх необходимого, ну как бы полигоны геософту и геопространственной бд нужны.
Дак вы 10 миллионов осеротевших точек нашли, или 10 миллионов осеротевших веев? Если точек, то это более ли менее понятно (их например бот менявший лицензию любил оставлять) и это запросто могло остаться в каком-нибудь Гондурасе где в начале был импорт, и местных кто хотел бы исправлять данные не нарисовалась, а потом прошёлся бот. 10м веев, как то подозрительно много. Обычно они есть но так, пара десятков на штат/область. Вроде keepright умел их находить. Вы можете этих сирот выгрузить с координатами чтобы посмотреть где они в основном?
Ждём, возможно вы придумаете api 0.7 или тип полигон. Хотя, разговоры ведутся от рождества СтивКоста, но это видимо не мешает особо жить, и тем кто мапит и тем кто контрибьютит, и даже тем кто занимается валидацией — как минимум не досуг.
Ну пилите свой формат, кто же вам мешает. Только чур чтобы сохранялась возможность версионировать данные и относительно легко обнаруживать конфликты. И сохранялась возможность указывать топологические взаимосвязи между объектами. (Общие точки дорог для перекрестков, вот это все). А ну и модель данных свободная которую каждый дополняет без единого authority.
Доклад на тему поиска, и смысл в том, что если вы программист и собрались хранить адреса, будьте готовы к тому, что у одного дома (у того что вы считаете домом и что в ваших данных будет фигурировать как дом) их может оказаться и 2 и 4 и больше.
Кадастровые они или почтовые, вы их должны находить, да еще, желательно уметь угадывать, какие из этих 27 ранжировать повыше.
Вот: «Москва, рощинский 2-й проезд, 8» osm.me/#!/ru/map/5/57.78623/52.99805/q/%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0,%20%D1%80%D0%BE%D1%89%D0%B8%D0%BD%D1%81%D0%BA%D0%B8%D0%B9%202-%D0%B9%20%D0%BF%D1%80%D0%BE%D0%B5%D0%B7%D0%B4,%208/
«Москва, 39-й км МКАД» тоже находится, но мкад и вбит в осм по сегментам, интерполировать киллометры мой подопечный пока не умеет. osm.me/#!/ru/id/hghnet-2919500296-m716947792/map/14/55.59932/37.5117/q/%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0,%2039-%D0%B9%20%D0%BA%D0%BC%20%D0%9C%D0%9A%D0%90%D0%94/
Я не вижу смысла мешать вам вести героическую борьбу. Как там по вашему, надо выпустить побольше говна, вот пожалуй и займусь на досуге.
Я редактирую этот гадюшник, почти 10 лет, использую данные ОСМ. Общался с теми кто данные использует и в классических гисах и более хитрых. Общался и с людьми из фб и Майкрософт которую. Это не проблема, от слова совсем. Многие кто использует осм, вообще никак не столкнуться с осиротевшими веями или нодами, на 20 тысяч использованных лишь один раз тэгов — тоже всем наплевать. Это не волнует ни крупных игроков ни мелких ни обычных маперов. Вам тоже самое говорят те кто осм использует на Хабре.
То что действительно напрягает комьюнити и вызывает споры, это порой излишне рвение нарисовать абы что, лишь бы побольше для хот. И как использовать импорты и платных редакторов от фб/эпл/МС так чтобы не угробить местные комьюнити. К бд особых притензий нет. Вы съездили бы на любую осмерскую конфу, да сопоставили бы ваш анализ с тем, чем участники проекта реально озабочены.
Да почему вы в этом уверены то?
Вы лично можете занимать свой ум любыми упражнениями. Но вы же не об этом на Хабре пишете, а о том что ОСМ помирает из за структуры данных в базе. Вам просто не нравится текущая структура данных, и вы пытаетесь найти вескую причину чтобы все переписать.
Немедленно — ничего. Если кому-то прям сильно мешает, ну починит (если например просто забыли навесить теги) или удалить. Зачем бежать расчёсывать там где не чесалось.
Помечать ворнингами веи, участников отношений, без тегов — а на что вы предлагаете их исправлять? Только пожалуйста в текущей модели данных.
Я вас весьма внимательно прочитал. Не смотря что вы используете свой язык и терминологию не свойственные ни для осм, ни для классических гисов.
Так, значит, не в шахматы а в покер, не миллион, а 300 тысяч, не выйграл, а проиграл. То есть, вы нашли несколько миллионов веев без тегов, записали их в ту же категорию ошибок, что и осеротевшие веи, и предлагаете автоматом это пофиксить. Удачного вам обсуждения ваших инициатив в osm-dev рассылке.
Дак api 0.6 это как раз про модель данных, это появление отношений. Старик Оккам говорил не плодить сущностей сверх необходимого, ну как бы полигоны геософту и геопространственной бд нужны.
Дак вы 10 миллионов осеротевших точек нашли, или 10 миллионов осеротевших веев? Если точек, то это более ли менее понятно (их например бот менявший лицензию любил оставлять) и это запросто могло остаться в каком-нибудь Гондурасе где в начале был импорт, и местных кто хотел бы исправлять данные не нарисовалась, а потом прошёлся бот. 10м веев, как то подозрительно много. Обычно они есть но так, пара десятков на штат/область. Вроде keepright умел их находить. Вы можете этих сирот выгрузить с координатами чтобы посмотреть где они в основном?
Ждём, возможно вы придумаете api 0.7 или тип полигон. Хотя, разговоры ведутся от рождества СтивКоста, но это видимо не мешает особо жить, и тем кто мапит и тем кто контрибьютит, и даже тем кто занимается валидацией — как минимум не досуг.
Ну пилите свой формат, кто же вам мешает. Только чур чтобы сохранялась возможность версионировать данные и относительно легко обнаруживать конфликты. И сохранялась возможность указывать топологические взаимосвязи между объектами. (Общие точки дорог для перекрестков, вот это все). А ну и модель данных свободная которую каждый дополняет без единого authority.
Что значит без описаний? Без тэгов совсем, или без name?
Привет, старожилы. Сломанные мультики, для геокодера, в общем то решаемая проблема, да и не так уж и остро она стоит.
Мне кажется главная проблема осм — психологическое выгорание.
Я бы предпочел ошибиться.
То что это не нормальные адреса, я и так понимаю.
Доклад на тему поиска, и смысл в том, что если вы программист и собрались хранить адреса, будьте готовы к тому, что у одного дома (у того что вы считаете домом и что в ваших данных будет фигурировать как дом) их может оказаться и 2 и 4 и больше.
Кадастровые они или почтовые, вы их должны находить, да еще, желательно уметь угадывать, какие из этих 27 ранжировать повыше.
Вот: «Москва, рощинский 2-й проезд, 8»
osm.me/#!/ru/map/5/57.78623/52.99805/q/%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0,%20%D1%80%D0%BE%D1%89%D0%B8%D0%BD%D1%81%D0%BA%D0%B8%D0%B9%202-%D0%B9%20%D0%BF%D1%80%D0%BE%D0%B5%D0%B7%D0%B4,%208/
«Москва, 39-й км МКАД» тоже находится, но мкад и вбит в осм по сегментам, интерполировать киллометры мой подопечный пока не умеет.
osm.me/#!/ru/id/hghnet-2919500296-m716947792/map/14/55.59932/37.5117/q/%D0%9C%D0%BE%D1%81%D0%BA%D0%B2%D0%B0,%2039-%D0%B9%20%D0%BA%D0%BC%20%D0%9C%D0%9A%D0%90%D0%94/