Пока под рукой районы, поселения, населенные пункты
http://wowik.000space.com/places/ru/
Адресованные домики и т.п. обрабатываются, но статистика не выводится. Надо будет придумать как.
Вот тут есть старая необновляемая страничка:
http://peirce.gis-lab.info/stat2
Воспользоваться Overpass API в режиме вывода данных count (не выводит геометрию, только считает объекты по условиям).
http://overpass-turbo.eu/s/grn - пример. Когда выдаст сообщение об ошибке, нажать View data, увидите JSON вот такого вида:
{
"version": 0.6,
"generator": "Overpass API",
"osm3s": {
"timestamp_osm_base": "2016-05-25T19:28:02Z",
"timestamp_areas_base": "2016-05-24T10:22:02Z",
"copyright": "The data included in this document is from www.openstreetmap.org. The data is made available under ODbL."
},
"elements": [
{
"count": {
"total": 1210,
"nodes": 1052,
"ways": 158,
"relations": 0,
"areas": 0
}
}
]
}
Документация по запросам: http://wiki.openstreetmap.org/wiki/Overpass_API
Еще один из инструментов по просмотру статистики http://wiki.openstreetmap.org/wiki/RU:OSM_Analytics/ . О нем была статья в Штосм.
Что-то он у меня в ФФ 43.0, не работает.
Имеется “городок” (скорее всего посёлок городского типа). Он указан, как “Городок”, а вот его территория, как “Граница села, деревни”, а имеет статус “Город районного значения”. (Население около 20к на 2015й)
Территория верно указана? (Граница села, деревни)
Выражайтесь пожалуйста в тегах, а не в не пойми чем.
Лучше скажите явно про какой город говорите, проверим.
Подскажите, есть ли какой-то софт для андроида, который позволяет ставить точки на треке вручную и только дождавшись повышения точности сигнала до требуемой?
Знаю, что API позволяет программе получать не только координаты, но и точность получаемого сигнала (программа GPS Essentials позволяет посмотреть эти данные в риалтайм в сыром виде). При картировании мне было бы очень полезно, дойдя от одного объекта до другого по прямой, остановиться, нажать кнопку на смартфоне, и стоять на месте, дожидаясь повышения точности до 5м. А точку на треке чтобы софт поставил только после этого (обозначив звуковым сигналом разрешение двигаться к следующей точке).
Традиционный софт, записывающий точки на треке в автоматическом режиме и независимо от текущей точности сигнала, оказывается не очень полезен для картирования, потому что точность запросто может на какое-то время упасть до 25-50м (никак об этом не предупреждая записывающего), что делает потом записанный трек практически бесполезным для последующего картирования.
Подскажите, как пешеходный навигатор прокладывает дорогу через точки, обозначенные как “ворота/калитка”? Территория школы, входы - это открытые весь день калитки. Сквозной проход возможен, за исключением ночного времени. По логике, пешеходный навигатор должен прокладывать сквозной маршрут через такую территорию. Правильнее будет обозначить эти точки как “калитка”, как “вход” или как “свободный проход/лаз”?
Зависит от навигатора. Как правило, роутинг должен игнорировать калитки, ворота, шлагбаумы, входы, если на них не стоит уточняющих тегов access=*
А если не дождётесь? В смысле, если точность так и не достигнет желаемой?
Навигаторы обычно фиксируют точку как есть, и дают возможность впоследствии ее положение уточнить - если требуется, если есть время и желание.
Там была правка 4 часа назад, возможно были ещё - например, стёрли ещё какой-то (неправильный/глючный) запрет поворота, который всё ещё есть в графе маршруто-прокладчиков.
Полагаю, дело в »отношении«. Двигаясь via эту точку по СКАД со стороны развязки, мы попадаем на участок графа, который включён в запретное отношение в качестве from и to одновременно.
А из-за этого »отношения« скоро (когда обновятся данные у маршрутизатора) будет невозможно движение через ту же точку в обратном направлении.
Передавайте привет diamondarm с десятью правками, среди которых ещё такой запрет.
Правки 4-5 часа назад не успели повлять на OSRM, все 4 правки https://www.openstreetmap.org/changeset/40038736 (о точке 616286298) не связаны с точкой http://www.openstreetmap.org/node/2556615840, я немного в шоке как так может быть, потому что у node/2556615840 нет запретов
прямой - маршрут нормально не строится, 3.3 km
обратный, ~300m
PS. no_u_turn, как мне кажется, правильно ставятся для запрета через двойную сплошную; повороты налево через двойную тоже нельзя
Я про то что возможно были ещё какие-то отношения, которые были недавно удалены и этих правок мы не видим.
Надо бы смотреть выгрузку недельной+ давности и все changeset-ы в районе с тех пор.
Но keepright и Turn Restrictions похожих проблем не показывают, так что в целом хз.
В том-то и дело, что в прямом маршруте алгоритм «натыкается» на точку via и далее учитывает from/to, которые представлены одним и тем же фрагментом линии дороги, что и «замыкает» или «запирает» возможность проезда. А в обратном маршруте алгоритм не видит после точки via участников данного отношения и не реагирует никак, т. е. для него дорога открыта.
Запрет, может быть, и правильный, но данный алгоритм (или все/большинство?) не различает, видимо, «лево/право/прямо/u-разворот». Он «видит» только «нельзя» («no») и «смотрит» откуда, куда и через какую точку, но не «каким именно манёвром».
По идее, для no_u_turn должно быть исключение, но его нет. JOSM, кстати, подсвечивает красным цветом тех участников отношения, которые имеют две разные роли одновременно.
В общем, с разворотами всё плохо на сегодня. В дополнение к указанной проблеме с ними — есть ещё отсутствие поддержки линий в качестве via.
P. S. Считаю, что отношение no_u_turn (в случае однолинейного представления графа) не несёт полезной нагрузки (случаи, когда оно имеет смысл, весьма экзотичны, на мой взгляд), зато стабильно ломает маршрутизацию в общем случае.
ИМХО, по такой логике проезд через сегмет стоящий в no_u_turn как from и to вообще не будет работать никогда. Но такие маршруты OSRM строит.
Да, я неточно выразился. «Сигналом» для срабатывания «триггера» (включения анализа запрета на участке графа) в алгоритме явно является участник отношения с ролью «from». Потом учитывается точка «via» и далее отслеживается «to». Причём, есть зависимость от требуемого направления прохождения участка с таким отношением.
Если попадаем на линию «from», потом идёт «via», а далее (по направлению движения!) — нет участников запрета, значит туда можно.
Если же попали на «from», а «via» у нас за спиной (потому что обратное направление!) и после такого «via» нам надо-то, как раз, на «to», а оно по условиям отношения является «запретным». Тут и возникает «взрыв мозга алгоритма». Закавыка именно с направлением движения и зависимостью от него расположения участников отношения.
Необходимо адаптировать топологию отношения, потому что она некорректна, всё-таки (теперь я в этом уверен).
Если via уже “у нас за спиной”, то зачем реагировать на него?
Отношение запрета должно влиять на маршрут, только если маршрут через все три элемента проходит в том порядке, в котором роли. Если в маршруте первым идёт from, потом via, потом to, тогда надо условие отношения. А если в маршруте сначала попадает via, а только потом to и оно же from, то нет.
Либо вы говорите по глюк конкретного алгоритма и тогда надо смотреть код, или что-то в вашеё/моей логике не так.