Да, использовать значение=* в качестве ключа уточняющего тега можно только тогда, когда данное свойство относится только к данному объекту, а не ко всей категории. Например, мы можем использовать residential=urban/rural, потому что residential=* относится только к landuse=residential, а не ко всем landuse=*.
Если же свойство относится ко всей категории (например, building:levels=* относится ко всем building=*), то в ключе уточняющего тега должен стоять ключ основного тега, а не какое-нибудь его значение. И тут не обойтись без *:type=*, да.
Когда писал, что *:type=* не имеет смысла, рассматривал только первый вариант. Почему-то не упомянул это, извините.
Считаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.
На форуме в теме «одно или двухвейная улица» периодически заикаются про маршрутизацию для спецтранспорта, которому двухвейность не должна быть препятствием для манёвров через двойную сплошную, так же и некоторые типы barrier. То же самое можно сказать про велосипедистов.
Извините, это здесь при чём?
Я имел в виду, что между ключами что-то:type=*, что-то_type=* и что-то=* нет никакой разницы, поэтому лучше использовать ключ что-то=*.
Я не говорил, что уточняющие теги не несут смысла.
Я говорил только о том, какую «форму», какой «шаблон» правильнее использовать для уточняющих тегов.
Тут кстати тоже разброд и шатание, ибо в других тегах уточнение задавалось бы в духе barrier:type или barrier_type
Считаю, что части ":type" и "_type" не несут никакого смысла, поэтому их можно отбросить.
Плохо что в редакторах кишки наружу торчат
Не знаю, в JOSM все ":type", "_type" и прочие выдумки мапперов спрятаны за чекбоксами и выдающими меню, в которых стоят понятные слова на человеческом языке.
Это сложно для программистов, которые используют данные OSM и вынуждены проверять, где используется ":type", где — "_type", а где — ещё что-то.
если бы сделали это более юзерфрендли, то может и пошёл бы продукт в массы.
У нас в OpenStreetMap для каждого типа зданий есть своё обозначение. Например, многоквартирные дома обозначаются тегом building=apartments, а частные — building=detached. И на основании значения тега building=* можно строить рендеринг и показывать домики с building=detached позже, чем другие здания.
Но нельзя (имхо) строить рендеринг на основании «у этого многоугольника площадь 100,1 кв. м, поэтому мы его покажем пользователю сейчас, а у этого — 99,9 кв.м, и поэтому мы его покажем на один зум позже».
Нет, про 3D я не говорил. Когда упоминал полезность высоких зданий для ориентирования — имел в виду ориентирование на местности. Например, когда перед человеком карта на мобильном устройстве, а он гуляет по городу.
Я понимаю этот совет так: при приближении карты к земле пользователю сначала показываются только большие по площади здания, а потом — все. Иллюстрация:
Это место на карте: ссылка.
Такой подход, на мой взгляд, плох, потому что может ввести пользователя в заблуждение (особенно, если он не станет опускаться ниже зума, на котором отсутствует половина домов).
Если при изменении масштаба карты появляются/исчезают объекты разных категорий (например, малозначимые ж/д пути появляются позже, чем основные), то это нормально. При правильном применении карта становится только лучше.
Но когда человек видит на карте какой-то площадной объект, то он подсознательно считает, что видит все существующие объекты этой категории. И тут он узнаёт, что всё совсем не так, и что в данный момент он видит только здания с площадью более N кв. м. Как-то это нехорошо, я считаю. Я специально сделал оговорку «площадные», потому что точечных объектов (POI) это не касается.
Если я понял этот совет неправильно, то, пожалуйста, поправьте меня.
Лично я, конечно, решу, как мне поступать. Тем более, не уверен, что мне вообще когда-нибудь придётся заниматься созданием картографического стиля :)
Если бы это касалось одного меня, то я вряд ли написал бы комментарий. Но, когда в обучающей статье, которую прочитает много людей, дают неправильные советы, это плохо. А, так как этот совет я посчитал плохим, то и написал свой комментарий.
С другой стороны в этом же слое хранятся данные о торговых центрах, складах и других весьма больших зданиях, которые на средних зумах будут хорошими ориентирами. Поэтому нужно разбить здания на категории по занимаемой площади и показывать уже частями, в зависимости от зума.
Очень, очень спорный совет.
Лично я, если вижу на определённом зуме здания, то предполагаю, что это ВСЕ здания, присутствующие в базе данных. И от этого отталкиваюсь при визуальном планировании маршрута, анализе карты и т. д. Но стоит «приблизиться» к земле — и появляется ещё куча домиков. Вау! Нехорошо так делать.
Например: квартал, в котором находится много жилых «свечек» (у которых маленькая площадь основания) и один большой торговый центр (его площадь гораздо больше). И что же, на определённом зуме вы будете рендерить только торговый центр!? Пожалуйста, не нужно. Ведь «свечки» гораздо лучше подходят для ориентира из-за их высоты.
Другой пример: металлургический завод и рядом — жилой квартал. Цеха (имеют большую площадь) будут показаны, жилые многоквартирные дома — нет. А между тем, рядовому пользователю интереснее расположение жилых домов, чем промышленных цехов.
Вот, составил список Android-приложений от Google, в которых есть боковое меню (снимок, возможно, не полный):
Gmail — боковое меню над Toolbar, присутствует анимация Menu-to-Arrow
Google+ Фото — боковое меню под Toolbar, присутствует анимация Menu-to-Arrow
Hangouts — боковое меню под ActionBar, анимация старая
Play Книги — боковое меню над Toolbar, присутствует какая-то анимация Menu-to-Arrow, как здесь: codepen.io/anon/pen/Gcnie
Play Маркет — боковое меню под Toolbar, присутствует анимация Menu-to-Arrow
Play Пресса — боковое меню над Toolbar, присутствует анимация Menu-to-Arrow
Play Фильмы — боковое меню над Toolbar, присутствует анимация Menu-to-Arrow
YouTube — не обновлялся боковое меню под ActionBar, анимация старая
Диск — боковое меню под ActionBar, вместо иконки статическая картинка — три полоски
Карты — ActionBar нет, боковое меню вызывается кнопкой
Новости и погода — не пользовался, но так показано на скриншотах в Google Play боковое меню под Toolbar
Мда. На фоне стараний Google унифицировать интерфейс приложений не только самой компании, но и всей экосистемы Android, такое многообразие одного и того же элемента интерфейса выглядит странно.
В Google Play всё вообще странно.
По гайдлайнам (и прошлым, и нынешним) контент должен затемняться, когда открывается боковое меню. На Главной странице затемняется не только контент, но и сам ActionBar. Непонятно, как они это сделали, а главное — зачем?
В то же время, на странице Мои приложения всё ок.
Если же свойство относится ко всей категории (например, building:levels=* относится ко всем building=*), то в ключе уточняющего тега должен стоять ключ основного тега, а не какое-нибудь его значение. И тут не обойтись без *:type=*, да.
Когда писал, что *:type=* не имеет смысла, рассматривал только первый вариант. Почему-то не упомянул это, извините.
Я имел в виду, что между ключами что-то:type=*, что-то_type=* и что-то=* нет никакой разницы, поэтому лучше использовать ключ что-то=*.
Я не говорил, что уточняющие теги не несут смысла.
Я говорил только о том, какую «форму», какой «шаблон» правильнее использовать для уточняющих тегов.
Не знаю, в JOSM все ":type", "_type" и прочие выдумки мапперов спрятаны за чекбоксами и выдающими меню, в которых стоят понятные слова на человеческом языке.
Это сложно для программистов, которые используют данные OSM и вынуждены проверять, где используется ":type", где — "_type", а где — ещё что-то.
А сейчас OpenStreetMap не «в массах»? :)
Наверное, highway=service + service=alley?
Вики-страница этого тега
Но нельзя (имхо) строить рендеринг на основании «у этого многоугольника площадь 100,1 кв. м, поэтому мы его покажем пользователю сейчас, а у этого — 99,9 кв.м, и поэтому мы его покажем на один зум позже».
Возможно.
Согласен.
Согласен.
Согласен.
Большое спасибо!
Я понимаю этот совет так: при приближении карты к земле пользователю сначала показываются только большие по площади здания, а потом — все. Иллюстрация:
Это место на карте: ссылка.
Такой подход, на мой взгляд, плох, потому что может ввести пользователя в заблуждение (особенно, если он не станет опускаться ниже зума, на котором отсутствует половина домов).
Если при изменении масштаба карты появляются/исчезают объекты разных категорий (например, малозначимые ж/д пути появляются позже, чем основные), то это нормально. При правильном применении карта становится только лучше.
Но когда человек видит на карте какой-то площадной объект, то он подсознательно считает, что видит все существующие объекты этой категории. И тут он узнаёт, что всё совсем не так, и что в данный момент он видит только здания с площадью более N кв. м. Как-то это нехорошо, я считаю.
Я специально сделал оговорку «площадные», потому что точечных объектов (POI) это не касается.
Если я понял этот совет неправильно, то, пожалуйста, поправьте меня.
Лично я, конечно, решу, как мне поступать. Тем более, не уверен, что мне вообще когда-нибудь придётся заниматься созданием картографического стиля :)
Если бы это касалось одного меня, то я вряд ли написал бы комментарий. Но, когда в обучающей статье, которую прочитает много людей, дают неправильные советы, это плохо. А, так как этот совет я посчитал плохим, то и написал свой комментарий.
Очень, очень спорный совет.
Лично я, если вижу на определённом зуме здания, то предполагаю, что это ВСЕ здания, присутствующие в базе данных. И от этого отталкиваюсь при визуальном планировании маршрута, анализе карты и т. д. Но стоит «приблизиться» к земле — и появляется ещё куча домиков. Вау! Нехорошо так делать.
Например: квартал, в котором находится много жилых «свечек» (у которых маленькая площадь основания) и один большой торговый центр (его площадь гораздо больше). И что же, на определённом зуме вы будете рендерить только торговый центр!? Пожалуйста, не нужно. Ведь «свечки» гораздо лучше подходят для ориентира из-за их высоты.
Другой пример: металлургический завод и рядом — жилой квартал. Цеха (имеют большую площадь) будут показаны, жилые многоквартирные дома — нет. А между тем, рядовому пользователю интереснее расположение жилых домов, чем промышленных цехов.
P. S. Извините за резкий тон сообщения.
P. S. Кому-то нужен этот список? Если да, напишите, пожалуйста, об этом, потому что я планирую перестать обновлять его.
Даже, наверное, лучше.
А тем временем…
Вот, составил список Android-приложений от Google, в которых есть боковое меню (снимок, возможно, не полный):
Мда. На фоне стараний Google унифицировать интерфейс приложений не только самой компании, но и всей экосистемы Android, такое многообразие одного и того же элемента интерфейса выглядит странно.
По гайдлайнам (и прошлым, и нынешним) контент должен затемняться, когда открывается боковое меню. На Главной странице затемняется не только контент, но и сам ActionBar. Непонятно, как они это сделали, а главное — зачем?
В то же время, на странице Мои приложения всё ок.
developer.android.com/intl/ru/tools/support-library/index.html#revisions
Это, получается, Toolbar должен быть внутри DrawerLayout.
Так, кстати, сделано в приложении Play Пресса.