“Номер дома” бывает и у территорий, и у подземных переходов, и у подъездов. Проще будет относиться к нему как к просто “номеру”.
По той же причине, по которой для place наряду с полигоном используют точки, и amenity наряду с территорией вешают на здание школы - потому что адрес на доме рядом с дорогой гораздо полезнее чем адрес где-то посередине (а то и вне) участка Г-образной формы. У зданий того, что может считаться центром нет, у участков - есть.
Одинаковых потому что в базе будет два объекта. По факту есть одна сущность - адрес, но у неё кроме площади есть центр.
Нет, всё именно так сложно. Кроме того, контура может и не быть.
Окай, пусть будет переопределением. Использование разных тэгов для одного и того же в зависимости от левых условий - это бред и landuse=forest.
Тэги не вводятся для поддержки адресации, тэги вводятся для обозначения объектов и их свойств.
Тут я задумался, а действительно ли номер дома в деревне относится к участку. Может быть именно потому что это не так адресов в деревне нет на ПКК.
В общем:
Использовать ли addr:lot - вопрос целесообразности. Необходимость в нём возникает только в одном случае: если в одной единице адресации (скажем, СНТ) возможны и дом, и участок с одним номером. Будут такие примеры - будет о чём говорить. Для “выделить из addr:housenumber” не-дома оно не работает, потому что в housenumber и так не только дома (и повторюсь, не вижу причин не рассматривать housenumber как просто “номер”). В остальном же addr:lot - всего лишь другое название для addr:housenumber.
Вопрос с “центром” адреса при площадном оном остаётся открытым, хотя, если предположение выше верно и в деревнях действительно адресуются дома, то уже не таким актуальным. Но тогда можно задать другой вопрос - как обозначить участок именно при этом доме?
Есть проблема. Если мы смешаем номера участков и номера домов в одну кучу, то не сможем потом составить отдельно карту с номерами домов и карту с номерами участков, т. к. мы не будем знать, где проставлен номер участка, а где - номер дома. Если все объекты полностью нарисованы, то можно различить addr:housenumber, проставленные на building, от addr:housenumber, проставленные на полигоны. Но ведь может возникнуть ситуация, когда номера домов и участков будут проставлены на точки из-за отсутствия на момент добавления данных в базу информации о геометрии домов и участков. Как тогда быть?
Важный момент - точки place используются вместе с полигоном, но не заменяют его. Удаление тегов с полигона и перенос их на точку не является корректным действием.
По поводу amenity=school/kindergarden, насколько я помню, редакторы не пришли к единому мнению: кто-то считает, что нужно ставить теги на здание, кто-то - что на всю территорию. Но вроде бы и туда, и туда отдельно взятые редакторы не ставят.
Все же не вполне понимаю в данном случае разницу между зданием и участком. Когда люди ищут дом, им часто нужна информация не сколько обо всём доме, сколько о том, где у этого дома расположен вход в него. Мы ставим номер дома на контур дома, а рендереры уже потом могут притягивать номера домов ко входам. Если считать, что у участка есть какая-то более важная точка, то, мне кажется, этой точкой следует понимать калитку, через которую на этот участок можно попасть. Но это опять же дело рендереров. При наличии одного entrance=main на контуре участка вполне можно притянуть номер участка на этот вход.
Ну так просто не нужно утягивать теги с номером участка с полигона на точку - вот и не будет проблемы лишнего объекта. Раз адрес относится к участку, то на весь участок его и нужно ставить.
Если контур неизвестен - ставим адрес на точку. Когда получаем информацию о контуре - на него. Мы же так делаем с номерами домов.
Вариант: gardening=yes - будучи проставленным на что-то, этот тег обозначает, что объект является садоводством.
Тогда переформулирую: тег place=allotments был введён для обозначения объектов, характеризующихся следующими свойствами: а) расположение вне пределов “стандартных” населённых пунктов; б) наличие внутренней адресации;
Необходимость возникает сразу, как только мы начинаем считать задачу выделения отдельных карт с номерами участков и номерами домов целесообразной. Она мне кажется целесообразной. Да, addr:housenumber ставится не только на дома, но ещё и на сооружения, памятники и прочие подобные объекты. Но объекты с разными housenumber при этом не пересекаются. Отдельно дом с номером, отдельно пруд с номером, отдельно памятник с номером. А тут в одном месте и номер участка, и номер дома (т. к. дом расположен на участке).
Мне кажется, такое в OSM никак не обозначается. Не припомню, чтобы как-то обозначали газон при доме, детскую площадку при доме, парковку при доме. Вариант: связывать объекты в отношения.
Кажется начинаю понимать. Да, это хороший аргумент за addr:lot.
Правильно. Я утверждаю что то же верно для адресов участков.
Я ставлю. Глупо было бы спорить с тем, что одинаково важны и территория, и её логический центр при наличии такового.
Автоматическое притягивание задачи не решает - входов может быть несколько и вход может быть обозначен не у всех участков. Случится то, что описано ниже.
Касательно проблемы в общем, попробую обрисовать ситуацию нагляднее:
Пусть есть некие адреса в деревне, которые всеми интерпретируются как номера домов. Потому что таблички висят на домах и в гости ходят в дома (либо, другой вариант - было известно, что это именно номера участков, но границы не были отрисованы и номера были проставлены точками на дома или где-то в районе калитки). Всё замечательно - номера рисуются вдоль дороги красивым рядком, что где понятно, роутинг работает правильно и ведёт к участку с фасада.
Но тут вдруг оказывается, что номера эти на самом деле обозначают участки (для второго случая - у кого-то доходят руки отрисовать границы), и номера переносятся, соответственно на них. А участки, напомню, формы весьма нехорошей - вытянутые, разной длины, а некоторые ещё и Г-образные. Например вот так: http://maps.rosreestr.ru/PortalOnline/?l=16&x=4283401.101181732&y=7635420.328046043&mls=map|anno&cls=cadastre
Что получаем: для рендеров и роутинга-то по-прежнему нужны точки, а точки все получают как могут. В итоге, номера как минимум съезжают дальше от дороги, к середине участков, причём все на разную длину. О читабельности карты уже можно забыть, потому что при поиске нужного номера нужно прыгать глазами зигзагом. Дальше - хуже: если участки расположены не под прямым углом к дороге, номера съезжают относительно домов, и сопоставить их становится ещё сложнее. Далее, если точки вычисляются тупым алгоритмом, они начинают попадать на чужие участки. Если более умным и, допустим, участок в глубине расширяется, то точки уедут ещё дальше. Если за участками есть другая дорога, к части адресов роутинг будет прокладываться по ней, т.е. с задней стороны где, возможно, вообще глухой забор. Ну и на сладкое - в каждом отдельном рендере и программе навигации это будет работать по-своему криво.
Собственно, вот и вся проблема.
Зачем это нужно?
Какая разница как он был введён, тем более что оба условия бессмысленны?
Двумя руками “за”. landuse=allotments должно ставится по факту, на огороды, а не на коттеджные посёлки с многоэтажными дворцами, вертолётными площадками и бункерами охраны, где кроме травы на газонах огородами и не пахнет. К некоторым садоводствам это тоже относится. И напротив, есть большие участки даже в больших городах, прилегающие к многоэтажкам и используемые жителями под грядки.
Надо приходить к единому мнению, у меня накопилась куча полученных на местности данных по СНТ, жду решения вопроса. Предлагаю окончательно остановиться на том, что предложил или предложит Dinamik, его схемы мне кажутся наиболее конкретными.
Не ждите
А если подробнее то посмотрите как нарисованы рядом эти участки- сделайте также, либо как вам более удобно. Это более разумно. Потому что даже если сейчас все скажут всё с завтрешнего дня делаем так, никто не говорит о том что несколько тысяч СНТ в мнговение ока перерисуются.
И чем сейчас плоха ситуация с тем что сейчас place ставим на всю площадь, а landuse в связке обсуждаем в силу того что СНТ являются маленькими по площади(не как в городе). Но мапперу ничего не мешает отделить place и landuse внутри него отдельными линиями. Посмотрите, как переводится place и как landuse тогда вы поймёте как логично и где использовать эти тэги.
А у дома/участка всегда будут addr:city…addr:street…addr:housenumber это что касается навигации.
допустимо ли ставить ворота на дороге а не в заборе если нет возможности нарисовать забор - не понятно как он идёт, но ворота есть и представляют из себя существенные препятствия?
может ли граница place=allotments одновременно быть ограждением или необходимо нарисовать ограждение отдельно параллельно (как быть если линии ограждения и границы place=allotments совпадают) ?
параллельно на расстоянии 1 м друг от друга идут дорога, забор и за ним дорога. Если я нарисую это на карте в реальном масштабе, стоит ли мне заботиться о том как это будет выглядеть на навигаторе или на web-карте (не сольются ли линии в более крупном масштабе)?
в СНТ есть дороги “побольше” которые ведут к нескольким обществам или являются центральными (как правило с покрытием) их думаю обозначить highway=residential и есть проезды, которые уже обозначены как highway=service + service=alley. Считаете ли Вы разумным рисовать дороги “побольше” как highway=residential?
могут ли ограждение с воротами и дорога ведущая через ворота иметь общую точку? Кажется да, потому что ворота бывают в ограждении а препятствие представляют для движения по дороге?
Дороги не бывают шириной 1 м. По ней машина не сможет проехать, а значит это уже не дорога, а что-то другое (пешеходная дорожка или тропа). Обычно ширина дороги не менее 3 м., а линия проводится по оси дороги - в итоге дистанция между линиями дорог будет минимум метров 5.
Конечно, и на такой дистанции линии на каких-то масштабах будут сливаться, но вот чего делать точно не стоит - так это искажать действительность в угоду красивой картинки в рендерере/навигаторе. Это один из самых больших грехов в OSM, к сожалению довольно распространённый.
Вполне. Более того, зачастую проезды внутри СНТ имеют название и участвуют в адресации, а значит так же вполне заслуживают гордого статуса residential. Покрытие и ширина дороги задаётся отдельными тегами.
Так что рисуйте как вам нужно и другим было понятно
По-другому вопросу: Одно из основных правил ОСМ не рисовать под рендер. ОСМ это БД. Вы наполняете БД - а рендер её отображает. Разные рендеры отображают её по-разному. У мапника действительно есть проблемы с не отображением. Так например у меня в городе amenity=recycling отображается и поэтому его используют. А amenity=waste_disposal (мусорки) нет. Так вот это не правильно. Где waste_disposal ставить recycling не правильно, и причина не важна. Бороться за то что бы добавили нужный тэг в отрисовку у меня не получилось пока что. Кто знает как это правильно сделать? А то я даже и тикет сделал: https://trac.openstreetmap.org/ticket/4473 )))
Да, но надо ещё добавить что подъездные дорооги к СНТ и сквозные дороги (например, ведущие в другие СНТ), принято обозначать как unclassified. Просто стволовой проезд по СНТ - residential, мелкие проезды - service.
Я даже не ожидал такого участия, спасибо всем кто ответил! Рисую понемножку, то там дорожку то тут дорожку. Нарисовал и уточнил уже кое-что в пригороде (новое здание и дорожки), и многое в окрестных СНТ. Теперь в соответствии с вашими рекомендациями буду уточнять СНТ. Активно использую OSM в туристком навигаторе наряду со снимками, очень доволен. Ещё раз благодарю!
Лично мне кажется, что какая-нибудь 15-я Огородная улица, по которой есть только десяток участков, этого гордого статуса не достойна
residential - это сквозной (или просто стволовой) проезд, не стоит загромождать карту остальными улочками - пусть будут service’ами.
Ситуация, когда есть дома по улице, а самой улицы нет (уже нет или еще нет), вполне нормальная. На домах ставится addr:street, а name нигде не ставится.
