Мда. Похоже, сейчас будет то же самое. Может, понизить и посмотреть на возражения?
Мда. Похоже, сейчас будет то же самое. Может, понизить и посмотреть на возражения?
думаю, да. Полагаю, у Севастопольского, Мичуринского и Алтуфьевского ш. должен быть один статус - secondary. По ним нет невнутримосковского трафика, фактически они тупиковые, да и пропускная способность у них на первый взгляд похожа. Но надо смотреть и соседние улицы - возможно, многим придется понизить статус. Вообще, в Москве во многих районах как-то мало residential улиц.
Мичуринский отличается тем, что продолжается за МКАД. То, что мало residential при такой плотности застройки не удивительно, если улица не тупиковая и что-то соединяет, то трафик на ней обычно весьма значительный.
Мичуринский отличается тем, что продолжается за МКАД.
ну и что? это же все равно территория Москвы, а потом Боровское шоссе вливается в Киевское. Как компромисс, можно понизить статус только Мичуринского, а Боровское оставить - все равно по нему (перекрыто из-за строительства метро Ломоносовский проспект) в центр сейчас гораздо меньше ездят.
Боровское, кажется, в любом случае ее стоит трогать.
Завтра в 17:00 встречаемся у входа в Парк Горького с Мануэлом Хохманном, одним из организаторов балтийской конференции. У кого вечер не занят, присоединяйтесь. Отдохнём. Мой телефон — +7 925 129-34-57.
Картовстреча будет через неделю, тоже в субботу. Выбираю между Волоколамской и Фрунзенской.
В Раменском районе появилась вторая деревня Островцы.
Была: http://www.openstreetmap.org/node/360001440
Появилась: http://www.openstreetmap.org/node/3621980354
По идее вторую точку нужно убрать - она грубо ошибочна (хотя бы название с маленькой буквы). Но вот где на самом деле должна быть точка центра мне не ясно. Насколько удачно указана текущая точка центра проще понять более местному человеку.
А ещё в Москве пересеклись границы районов - http://www.openstreetmap.org/relation/1320424#map=19/55.98103/37.22518
Район Савёлки идёт по руслу реки, а Москвы рядом.
Народ, такой вопрос. Мне по работе необходимо знать управляющую компанию конкретного дома, списки есть, хочется вбить в osm с целью смотреть на ноутбуке, собственно вопрос, у некоторых шаражек есть внутренее деление нп-р, го. Жуковский УК Теплоцентраль ЖКХ имеет шесть ЖЭУ. Сами УК обозначаю тегом operator, как обозначить ЖЭУ, чтоб не возникало вопросов, branch?
Народ, такой вопрос. Мне по работе необходимо знать управляющую компанию конкретного дома, списки есть, хочется вбить в osm с целью смотреть на ноутбуке, собственно вопрос, у некоторых шаражек есть внутренее деление нп-р, го. Жуковский УК Теплоцентраль ЖКХ имеет шесть ЖЭУ. Сами УК обозначаю тегом operator, как обозначить ЖЭУ, чтоб не возникало вопросов, branch?
Я бы указывал у operator=* конкретное юр. лицо, первое в иерархии. Компанию делал отношением Relation:site - дальше несколько копмпаний объединял в УК, другой Relation:site.
https://wiki.openstreetmap.org/wiki/RU:Relation:site
Похожее есть в медицинских, пожарных, полицейских, судебных, образовательных, технических городских компаниях:
город - район - участок
За участком могут следить разные подрядчики. В сфере ЖКХ “участок” более расплывчатый. Это ведь:
- группа домов
- группа landuse=residential (если, конечно, у тебя хватит сил и терпения их точно рисовать и перекраивать каждый раз)
На мой взгляд проще всего группировать дома в отношения. Как разберешься как в JOSM искать по отношениям сразу поймешь почему: https://josm.openstreetmap.de/wiki/Help/Action/Search
И это от борца за идеальность, не нужно использовать отношения для коллекций - это путь к дублированию. operator и branch тут всё решают. Хранить всё иерархию в геобазе не надо.
И это от борца за идеальность, не нужно использовать отношения для коллекций - это путь к дублированию. operator и branch тут всё решают. Хранить всё иерархию в геобазе не надо.
Расскажи это Украинцам где отношения - основной способ хранить двуязычную адресацию.
operator и branch может быть недостаточно.
Подрядчик не должен быть частью какой-либо структуры.
К твоему сведению любой дом обслуживается:
- школой
- пожарными
- полицией
- вывоз мусора
- газовой службой
- электриками
- сантехниками
- телекомами
- управляющей компанией
- и т.д.
Как ты это умудришься уместить в operator и branch?
Хранить всё иерархию в геобазе не надо.
Если данные не из бугалтерской отчётности, а по факту и настоящим объектам и если будет обновлять и пользоваться - пусть хранит что хочет.
К твоему сведению любой дом обслуживается:- школой- пожарными- полицией- вывоз мусора- газовой службой- электриками- сантехниками- телекомами- управляющей компанией- и т.д.
К твоему сведению они обслуживают территорию, а не дом. Вот её и надо отмечать.
Если данные не из бугалтерской отчётности
Так вот как раз от туда и предлагают хранить. Кто там кому подчиняется юридически никак не привязаны к геоданным.
К твоему сведению они обслуживают территорию, а не дом. Вот её и надо отмечать.
Обслуживают объекты физического мира:
- трубы,
- здания,
- фундаменты,
- распределительные щиты и подстанции
Электрики не чинят землю.
Сантехники и газовые службы не проверяют землю.
Почты, школы и поликлиники не обслуживают земли, а конкретные здания и конретных жильцов и квартиры.
Данные из бугалтерии - не нужны.
Настоящие огранизации - сколько угодно.
Учёт технических объектов прямо в OSM - пожалуйста.
Кто там кому подчиняется юридически никак не привязаны к геоданным.
Напрямую - нет. Отношения содержат другие отношения, которые содержат геоданные.
Обслуживают объекты физического мира:
Угу, которые попадают в зону их ответственности. Так зачем заводить по пачке отношений на каждый куст который может загореться и его приедут тушить пожарные, когда можно показать, что всё что тут внутри обслуживает эта бригада.
Напрямую - нет. Отношения содержат другие отношения, которые содержат геоданные.
Ну так и указывай для POI организации кто у неё хозяин/барин, отношения тут не сдались.
когда можно показать, что всё что тут внутри обслуживает эта бригада
Когда-то можно, когда-то - нет. Если есть настоящий список по конретным домам - пусть вводит и обновляет.
Нет, не все дома в одной области обслуживаются одной компанией (подрядчиком).
Нет, они обслуживают не все дома в этой области, а только часть.
Следующие по наивности заявления:
- все области в городах landuse=residential.
- здесь точно промзона (рисует 10^2 км 100^2 км landuse=*)
- обведу границу города вокруг жилых домов и Bing
- здесть точно дорога для автомобилей, нариусую её по Bing
Нет, не все дома в одной области обслуживаются одной компанией (подрядчиком).
Речь шла про школу, милицию, больницы и т.д. Про управляющую в operator не кто не спорил.
Речь шла про школу, милицию, больницы и т.д.
Ну так и что? Я не знаю школ и поликлиник которые заявляют о зоне обслуживания площадью.
Тем более с гео-координатами.
Тем более с эксклавами и анклавами.
У всех списки адресов. Большинство этих списков - ошибочные.
Список Angrycat вообще ни при чём.
Я не знаю школ и поликлиник которые заявляют о зоне обслуживания площадью.
Ну на кой х…н населению поворотные точки. Там площать представлена в удобнов виде, как список улиц, и домов, если не вся улица попадает. Если состряпать тепловую карту, ты можно увидеть ту самую площадь.
Ну или приведите пример, где больница обслуживает рандомно натыканные домики по всему городу.
Там площать представлена в удобнов виде, как список улиц, и домов, если не вся улица попадает. Если состряпать тепловую карту, ты можно увидеть ту самую площадь.
Я ещё раз говорю что это упрощения из категории ковыряния в носу.
В этой площади будут:
- выселенные дома
- жилые дома не используемые как жилые
- жилые дома не используемые совсем
- юридически жилые дома, а по факту - нет
- пропуски жилых домов, не жилых юридически
Если список Angrycat по фактическим объектам - пусть вносит и обновляет. Как этот список проще тегировать - пусть выбирает.