Выше приводилась классификация, надеюсь что такое “Внутридворовый гостевой парковочный карман” понятно большинству, чтобы добавить на это дело дополнительный тег, если свербит обозначить его парковкой.
Ну если это конкретика, а не что-то-minor, я только за.
Может дополнить тег parking чем-то подобным:
“Гостевой парковочный карман”
parking=guest_parking
?
Нет, parking= это физический тип парковки, и это parking=surface.
Нужно что-то типа parking:(importance или coverage или usage)=(house|neighbourhood|…).
А гостёвости тут не больше чем на любой другой стоянке - у дома постоянно ставят машины лиди, живущие в этом доме.
parking:use=residental ?
( по аналогии с building:use = residental )
А пусть Amigo расскажет какие бы парковки он хотел видеть в навигаторе, будет о чём подумать.
parking:use это полезно, но не даёт представления о размере - это и парковка на 4 машины перед подъездом, и на сотню на квартал.
не даёт представления о размере
Тогда нужен тэг для примерного размера. В имеющийся capacity надо точное число писать.
capacity:estimate ?
Набор предопределённых: <5|<10|5-10|10-20 + базовые правила: <x|>y|x-y
Прежде чем городить эти схемы, надо понять зачем это вообще нужно. Если цель - “чтобы рисовалось меньше иконок P”, к тэггированию это вообще никакого отношения не имеет.
Мыло и мочало начинай сначала, цель дополнить неполную классификацию парковок вполне себе официальным определением “Внутридворовый гостевой парковочный карман”, дабы была возможность отфильтровать псевдо парковки, отмечаемые единицами (как, например, стало возможным фильтровать гаражи, благодаря access).
В реале в основном нужно примерно следующее:
Плюс есть ли и как проехать на парковку магазина/учреждения.
Потому что:
И parking=*, имхо, для этого дополнения вполне себе подходит, чтобы не плодить сущности.
Я понял - вам нужны публичные парковки. Тогда с головой хватит чего-то типа parking:use=residental | public
А я считаю, что не подходит. Если посмотреть на текущую номенклатуру значений parking=
то становится понятно, что ваш “Внутридворовый гостевой парковочный карман” является разновидностью parking=surface.
И если цель
то должен быть дополнительный уточняющий тэг, не сносящий ни amenity=parking, ни parking=surface
А по количеству сущностей… наша одна доп. сущность - детский лепет по сравнению с ворохом всяких “parking:condition:right:time_interval=Mo-Fr 07:00-09:00” 
Вопрос остался…
хм, действительно ул. входят
http://yav.gis-lab.info/settlements/n292885144-w48374808-o75545000-k7400001300000
попробуй как реши
http://openstreetmap.ru/#zoom=14&lat=57.71111&lon=60.37158&marker=1&layer=M
мультиполигоном
Возможно и так, но хотелось бы и конкретный тип парковки указать “карман” если он и surface…
Но перейдем ко второму шагу - как это дело внедрить в рекомендии к amenity=parking?
А зачем вообще обозначать парковочные карманы как парковку? Ведь само понятие паркинг несколько отличается от того места, где можно бросить машину
¿Может просто amenity=highway?
Смысловая нагрузка не на столько уж и велика… Какую цель приследуете?
j-wills, перечитайте тред. :3
Как лучше размечать частный сектор? Выбираю между вариантов:
- Все пространство с жилыми домами метить как residential.
- Метить отдельно пространства, ограниченные со всех сторон дорогами, тогда на эти сектора можно будет навесить и, к примеру, barrier=fence. Но это больше геморроя, естественно.
- Разбивать сектора по дорогам определенного уровня, secondary, например. Поскольку город маленький, вариант мутирует в 1-й.
- Еще как-то.
Глянул Саранск, для примера – видел там 1 и 2. В общем, как лучше?
Все варианты приемлимы, я чаще придерживаюсь 2-го: один квартал - один полигон.
Да, в общем-то, все варианты подойдут, но если есть снимки выского разрешения, то я бы рекомендовал использвать 2-й вперемешку с 3-м с разбивкой по residential. Если же снимков нет, то 1-й вперемешку с 3-м с разбивкой по tertiary.
А как метить административные районы города? Город – районный центр.