Pull to refresh
6
0
Send message
Да, использовать значение=* в качестве ключа уточняющего тега можно только тогда, когда данное свойство относится только к данному объекту, а не ко всей категории. Например, мы можем использовать 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 не «в массах»? :)
barrier=bollard
bollard=removable
material=concrete
height=0.7
Хе-хе, хотел бы я посмотреть на «барьер, убираемый, бетонный, высотой 70 см» :)
highway=alley
Наверное, highway=service + service=alley?
Вики-страница этого тега
У нас в OpenStreetMap для каждого типа зданий есть своё обозначение. Например, многоквартирные дома обозначаются тегом building=apartments, а частные — building=detached. И на основании значения тега building=* можно строить рендеринг и показывать домики с building=detached позже, чем другие здания.

Но нельзя (имхо) строить рендеринг на основании «у этого многоугольника площадь 100,1 кв. м, поэтому мы его покажем пользователю сейчас, а у этого — 99,9 кв.м, и поэтому мы его покажем на один зум позже».
Но я считаю, что вы слишком категоричны

Возможно.
карты бывают разные, и задачи у них тоже разные

Согласен.
Что уместно в одном случае, не подойдёт в другом

Согласен.
А универсальный совет один — всегда думать головой

Согласен.
Я немного отредактировал текст примера.

Большое спасибо!
Нет, про 3D я не говорил. Когда упоминал полезность высоких зданий для ориентирования — имел в виду ориентирование на местности. Например, когда перед человеком карта на мобильном устройстве, а он гуляет по городу.

Я понимаю этот совет так: при приближении карты к земле пользователю сначала показываются только большие по площади здания, а потом — все. Иллюстрация:

Это место на карте: ссылка.

Такой подход, на мой взгляд, плох, потому что может ввести пользователя в заблуждение (особенно, если он не станет опускаться ниже зума, на котором отсутствует половина домов).

Если при изменении масштаба карты появляются/исчезают объекты разных категорий (например, малозначимые ж/д пути появляются позже, чем основные), то это нормально. При правильном применении карта становится только лучше.
Но когда человек видит на карте какой-то площадной объект, то он подсознательно считает, что видит все существующие объекты этой категории. И тут он узнаёт, что всё совсем не так, и что в данный момент он видит только здания с площадью более N кв. м. Как-то это нехорошо, я считаю.
Я специально сделал оговорку «площадные», потому что точечных объектов (POI) это не касается.

Если я понял этот совет неправильно, то, пожалуйста, поправьте меня.

Лично я, конечно, решу, как мне поступать. Тем более, не уверен, что мне вообще когда-нибудь придётся заниматься созданием картографического стиля :)
Если бы это касалось одного меня, то я вряд ли написал бы комментарий. Но, когда в обучающей статье, которую прочитает много людей, дают неправильные советы, это плохо. А, так как этот совет я посчитал плохим, то и написал свой комментарий.
С другой стороны в этом же слое хранятся данные о торговых центрах, складах и других весьма больших зданиях, которые на средних зумах будут хорошими ориентирами. Поэтому нужно разбить здания на категории по занимаемой площади и показывать уже частями, в зависимости от зума.

Очень, очень спорный совет.

Лично я, если вижу на определённом зуме здания, то предполагаю, что это ВСЕ здания, присутствующие в базе данных. И от этого отталкиваюсь при визуальном планировании маршрута, анализе карты и т. д. Но стоит «приблизиться» к земле — и появляется ещё куча домиков. Вау! Нехорошо так делать.

Например: квартал, в котором находится много жилых «свечек» (у которых маленькая площадь основания) и один большой торговый центр (его площадь гораздо больше). И что же, на определённом зуме вы будете рендерить только торговый центр!? Пожалуйста, не нужно. Ведь «свечки» гораздо лучше подходят для ориентира из-за их высоты.

Другой пример: металлургический завод и рядом — жилой квартал. Цеха (имеют большую площадь) будут показаны, жилые многоквартирные дома — нет. А между тем, рядовому пользователю интереснее расположение жилых домов, чем промышленных цехов.

P. S. Извините за резкий тон сообщения.
  • Play Маркет — боковое меню над Toolbar, анимации нет
  • Диск — боковое меню над Toolbar, присутствует анимация Menu-to-Arrow
  • Карты — боковое меню над Toolbar, анимации нет


P. S. Кому-то нужен этот список? Если да, напишите, пожалуйста, об этом, потому что я планирую перестать обновлять его.
Opportunity — как Windows XP.
Даже, наверное, лучше.
Вчера пришло обновление Google Play:
  • Play Маркет — боковое меню над Toolbar, присутствует анимация Menu-to-Arrow
И что в них измененилось по сравнению с моим первым списком?
Я их написал ещё раньше.
Некоторые приложения были обновлены, поэтому нужно и список обновить:
  • Gmail — боковое меню над Toolbar, анимации нет
  • Hangouts — боковое меню над Toolbar, анимации нет
  • YouTube — боковое меню над Toolbar, присутствует анимация Menu-to-Arrow
  • Новости и погода — боковое меню над Toolbar, присутствует анимация Menu-to-Arrow
Думаю со временем исправят.

А тем временем…

Вот, составил список 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. Непонятно, как они это сделали, а главное — зачем?
В то же время, на странице Мои приложения всё ок.
Эту строчку добавили только в последней версии AppCompat Library (v21)
developer.android.com/intl/ru/tools/support-library/index.html#revisions
Updated ActionBarDrawerToggle, which contains the menu-to-arrow animation
Можно пожалуйста ссылку?
Это, получается, Toolbar должен быть внутри DrawerLayout.

Так, кстати, сделано в приложении Play Пресса.
Красиво, только в Android переход из стрелки в три полоски происходит по часовой стрелке, а у тебя против.

Information

Rating
Does not participate
Registered
Activity