Добро пожаловать на форум OSM Russia! (оффтоп здесь)

Serzhanya · 2016-05-01 08:58:43

fserges wrote:

А что случилось с Северо-Кавказским федеральным округом?

Попал под раздачу:

LLlypuk82 · 2016-05-01 09:21:26

Там попутно и новый континент образовался?

BushmanK · 2016-05-01 18:00:35

Т.е. они считают, что если Абхазия или Южная Осетия войдут в состав России, то они будут присоединены к СКФО, что автоматически делает его границу спорной. Весьма смелое предположение.

Serzhanya · 2016-05-01 22:39:29

Всё прозаичнее - автор ошибся, когда правил границу (видимо из-за разницы использования admin_level=3 для разных стран). Уже исправлено.

Last edited by Serzhanya (2016-05-01 22:48:37)

fserges · 2016-05-02 08:52:34

Спасибо!

chnav · 2016-05-02 19:12:46

При общении с новым пользователем он указал что запрещена регистрация на форуме. Я отлогинился и зашел на страницу http://forum.openstreetmap.org/register.php - действительно посылает ((

This forum is not accepting new registrations.

Last edited by chnav (2016-05-02 19:13:35)

Max Vasilev · 2016-05-02 19:46:19

На форуме никогда не было регистрации. Сюда логиняться аккаунтом из OpenStreetMap.

gryphon · 2016-05-02 19:46:45

chnav wrote:

При общении с новым пользователем он указал что запрещена регистрация на форуме. Я отлогинился и зашел на страницу http://forum.openstreetmap.org/register.php - действительно посылает ((
This forum is not accepting new registrations.

Какая регистрация? Доступ же по OSM-овской учетке

chnav · 2016-05-02 20:25:54

Вот что происходит если пароли вводятся автоматом последние 5 лет )) Я ~~с прямым углом~~ с Wiki перепутал.

BushmanK · 2016-05-02 22:54:51

Счастье пришло, откуда не ждали: https://wiki.openstreetmap.org/wiki/User:Richard создал https://wiki.openstreetmap.org/wiki/Wel … edia_users где собрано немалое количество базовых принципов и понятий OSM, которые были раньше либо разбросаны по другим страницам либо вообще упоминались косвенно. Теперь можно тыкать в эту страницу многих, кто заводит споры по одному и тому же вопросу в десятый раз. Как минимум, упомянуто следующее:
- требование объективности данных
- требование фактического характера данных (мнения не нужны, нужны факты)
- кратко изложена политика в отношении копирования данных из других источников (что не разрешено, то запрещено, упражнения в "серой зоне" не приветствуются)
- отсутствие принципа значимости
- не мапить под рендер, а максимально объективно отображать данные
- OSM - это пространственная база данных
- не следует создавать коллекции, используя отношения

Неплохое дополнение к FAQ, я считаю. Даже сподобился перевести на русский.

Last edited by BushmanK (2016-05-02 23:42:46)

d1g · 2016-05-03 02:55:56

Очнулся называется, Zkir сказал уже всё 6 лет назад остальное было c 2009. Оставшееся - повторение основ OSM, которые User:Richard ни писал, ни читал, ни обсуждал, даже на вики:

http://wiki.openstreetmap.org/w/index.p … on=history
http://wiki.openstreetmap.org/w/index.p … on=history

Last edited by d1g (2016-05-03 03:26:31)

BushmanK · 2016-05-03 03:32:32

На российского человека почему-то содержание статей в Wiki производит иногда магическое впечатление. А на форумные сообщения всем всегда плевать.

Last edited by BushmanK (2016-05-03 03:32:57)

chnav · 2016-05-03 08:30:06

В связи с переходом на ноды с 64-битным ID в ОСМ возникает логичный вопрос - зачем они вообще нужны ? 31(32) бит дает по широте(долготе соответственно) разрешение 0.9 см, грубо окружность 40000км / 2^32. Для сравнения, сейчас стандартный OSM-файл 7 знаков после запятой или 1.1 см по широте. Зачем нужен этот геморой ?

Кто не понял - если покрыть всю землю сеткой 1x1 см либо 0.0000001° x 0.0000001° то каждая точка будет иметь уникальную координату, однозначно выражаемую в 63 bit (31 для широты + 32 для долготы). Конвертация геодезических или любых прямоугольных координат в Node ID сводится к умножению-делению, а не поиску по таблице.

PS: liosha давно говорил о ненужности ID, но это было во времена 32 бит и не нашло понимания.
PPS: единственная сложность, которую я вижу - хранение истории конкретного нода и его тегов, но к координатам не имеет отношения.

Мы смогли пережить смену лицензии, а переход на API с прямым хранением координат, без затычки в виде Node ID, просто неизбежен. Весь мир, все ГИС хранят координаты, только ОСМ через ~~одно место~~ node id ))

Last edited by chnav (2016-05-03 09:05:05)

d1g · 2016-05-03 09:13:16

Отказ от iD у точек - это навязывание только гео-функций.

Со стороны гео-разработчика непонятно нафига оно для без теговых node, но для тегов node получается циферный идентификатор, который ещё в школе на уроке информатики должны были объяснять.

Одна цифорка лучше двух вещественных чисел, а как только начинаются вещественные числа - это численная стабильность, да ещё замороченная геоидими и ещё чем.

У безтеговых node - да, абсолютно ненужная.

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

Last edited by d1g (2016-05-03 20:25:01)

chnav · 2016-05-03 09:41:16

d1g
Откуда взялись вещественные числа я не понял, можете считать это числами с фиксированной точкой, читай целыми. Что касается нодов с тегами - id должен быть у объекта "POI", "WAY", "AREA", а не у координаты.
Как говорили ранее гемор с хранением координат через node id придумали из-за ограничений SQL, а не какого-то глубинного смысла. Пытались сэкономить на идентификаторах - пришли к 64 бит.
Мне-то всё-равно, но когда видишь что для тупого перевода "геометрии" в координаты требуются десятки гигабайт mapped array и сутки переваривания планеты при любом импорте - что-то в этом королевстве не так.

Last edited by chnav (2016-05-03 09:47:20)

pfg21 · 2016-05-03 10:12:29

При внесении осм даных в рабочую базу можно дропить ид безтеговых точек, будет желаемое. Коррежить уже отработанную давно работающую систему... ну вы поняли.

chnav · 2016-05-03 12:21:50

pfg21 wrote:

При внесении осм даных в рабочую базу можно дропить ид безтеговых точек, будет желаемое. Коррежить уже отработанную давно работающую систему... ну вы поняли.

Это бзик такой в ОСМ - любая операция должна сводиться к препроцессингу и внесением в базу - на меньшее не согласны ))

Я понимаю что никто ничего не изменит, но представим обычный файл osm-xml и операцию геокодинга point-in-polygon. Сколько телодвижений надо сделать и сколько ресурсов требуется сейчас, а сколько - если каждый вей будет состоять из готовых координат (shp).
Cуть проста как три рубля, заменить одни id - 64-битные в текущем варианте + 64 бит на саму координату (итого 128 бит, которые предварительно нужно транслировать через mapped array), на другие id, готовые 63-битные координаты. Это также решает вопрос с мертвыми id, которые висят в базе впустую. Кто-то нарисовал криво-косо, или вообще фейк - id уже заняты и никогда не вернутся в общий пул. Когда пул закончится, будем работать с 80-96-128-bit id ))

(added)
Где бы посмотреть статистику сколько нодов в ОСМ имеют минимум один тег, т.е. несут функцию POI...

(added2)
В памяти всплывает что основной базе ОСМ данные переехали с MySQL на Postre/PostGIS. Может они уже хранятся шейпами ? В этом случае достаточно добавить протокол обмена в дополнение к osm-xml, чтобы не гонять данные туда-обратно через node id.

Last edited by chnav (2016-05-03 12:44:53)

OverQuantum · 2016-05-03 13:18:36

chnav wrote:

В связи с переходом на ноды с 64-битным ID в ОСМ возникает логичный вопрос - зачем они вообще нужны ? 31(32) бит дает по широте(долготе соответственно) разрешение 0.9 см, грубо окружность 40000км / 2^32. Для сравнения, сейчас стандартный OSM-файл 7 знаков после запятой или 1.1 см по широте. Зачем нужен этот геморой ?
Кто не понял - если покрыть всю землю сеткой 1x1 см либо 0.0000001° x 0.0000001° то каждая точка будет иметь уникальную координату, однозначно выражаемую в 63 bit (31 для широты + 32 для долготы). Конвертация геодезических или любых прямоугольных координат в Node ID сводится к умножению-делению, а не поиску по таблице.

1) Сейчас могут быть 2 точки с одинаковыми координатами, но не связанные. Если две линии используют одну точку (один node ID), то они связанны. А если нет - то не связанны. В этом случае можно рисовать многослойную и т.д. геометрию и будет понятно, что с чем связано.
Если точка будет иметь только координаты, тогда будет не ясно - связаны ли разные объекты, использующие точку с одними координатами.
Вот, например, если сейчас нарисован лес и река, граница "в стык" - по одним и тем же одним точка. Сейчас если двигаешь точку, двигается граница и того, и другого. А если точка будет иметь только координаты, тогда надо будет отдельно двигать обе точки отдельно или выделять все точки в данном месте.
2) Если не будет связи геометрии, чаще будут происходить наложения и разрывы нарисованного "в стык". Подвинул лес на 1см - и его граница оторвалась от границы реки. А то и где-то оторвалась, а где-то наложилась.
А если всегда подразумевать, что одинаковые координаты означают связь геометрии, то будут происходить случайные "прилипания" точек одних объектов к другому в процессе смещения и т.д.
3) Если точки всегда лежат на координатной сетке, то при каждом повороте, масштабировании и т.д. будет деградировать точность геометрии. Нарисовали строго прямые углы, повернули несколько раз - оп, они уже не совсем прямые. Сейчас геометрия "деградирует" только при загрузке в базу (ну если в JOSM рисовать).

chnav wrote:

Где бы посмотреть статистику сколько нодов в ОСМ имеют минимум один тег, т.е. несут функцию POI...

https://taginfo.openstreetmap.org/repor … statistics
Number of nodes with at least one tag: 109 710 280
Percentage of nodes with at least one tag: 3.27%

Last edited by OverQuantum (2016-05-03 13:22:22)

andygol · 2016-05-03 14:16:31

http://resultmaps.neis-one.org/osm-disc … /48.5/98.6

Контора пишет - комментарии к наборам правок! Оо

d1g · 2016-05-03 20:34:21

chnav wrote:

(added)
Где бы посмотреть статистику сколько нодов в ОСМ имеют минимум один тег, т.е. несут функцию POI...
(added2)
В памяти всплывает что основной базе ОСМ данные переехали с MySQL на Postre/PostGIS. Может они уже хранятся шейпами ? В этом случае достаточно добавить протокол обмена в дополнение к osm-xml, чтобы не гонять данные туда-обратно через node id.

Нужно ещё учитывать что безтеговые точки могут быть в отношениях. Удалять безтеговые точки просто так это вообще-то, моветон, сначала нужно убедиться в отсутсвии предков (линий отношений).

Нужно ещё учитывать что безтеговые точки могут использовать в двух way или отношениях. И скачивание предков общей точки приведёт с целостным данным хотя бы на этой части.

OverQuantum примерно то же сказал.

pfg21 · 2016-05-03 22:15:56

chnav, в путаете исходники и скомпилированную систему.
действительно никто в здравом уме не будет использовать исходники в работе, они для этого не подготовлены. исключение - скриптовые языки, да и то в них используется для ускорения работы предкомпилированный байт-код.
явный пример ядро линукса, на кернел.орг лежат исходники, содержащие в себе огромное количество различного кода для кучи различной аппаратуры. А конечный продукт, ввиде скомпиленного ядра содержит только то, что нужно, плюс вместо текстовых индентификаторов функций в нем используются прямые указатели на нужные участки кода. Если бы в исходниках вместо человекочитаемых имен функций/переменных использовались машиночитаемые указтаели-индентификаторы (как в скомпиленном варианте) то это была большая проблема для редакторов исходников.

самый большой проблемой в свете высказываний, на мой взгляд является то, что в осм есть апи только к исходникам.
Нашелся бы умный человек, создавший апи для конечного использования, к примеру выдаче объектов в виде gejson, аль чего подобного, где без дополнительных запросов и разбора структуры, сразу имеется имеется список точек для отображения, то таких вопросов бы не возникало.

Last edited by pfg21 (2016-05-03 22:17:49)

OverQuantum · 2016-05-03 22:20:03

Jake Strine wrote:

Что-то как-то тихо и мимо форума "прошли" снимки Sentinel 2. Хотя конечно Ландсатом мало тоже кто пользуется, но всё же. Испробовал их - и очень доволен результатом. Детализация заметно увеличилась в сравнении с Ландсатом (10 мп настоящих против 15 мп "паншарпенинговых")
...
Из минусов стоит отметить, то как подаются снимки. Архивом с несколькими снимками-гранулами - и средний вес около 6-7 Гб.

Попробовал. Действительно около 10 метров, и есть свежие, но на многих снимках облака. Раз в 12 дней превращается в "примерно раз в год".

Но интересно, что там помимо видимых каналов есть ещё 9. Вот полный перечень с базовыми длинами волн и разрешением (отсюда):
B01 - 443 nm, 60m (visible blue)
B02 - 490 nm, 10m (visible blue)
B03 - 560 nm, 10m (visible green)
B04 - 665 nm, 10m (visible ~red)
B05 - 705 nm, 20m (VNIR)
B06 - 740 nm, 20m (VNIR)
B07 - 783 nm, 20m (VNIR)
B08 - 842 nm, 10m (VNIR/SWIR)
B8A - 865 nm, 20m (VNIR/SWIR)
B09 - 940 nm, 60m (VNIR/SWIR)
B10 - 1375 nm, 60m (SWIR)
B11 - 1610 nm, 20m (SWIR)
B12 - 2190 nm, 20m (SWIR)
Есть идеи, можно ли какую-то информацию извлечь из таких каналов, сверх RGB из B02+B03+B04?
Можно ли отличить, скажем, заболоченный лес от обычного?

BushmanK · 2016-05-03 22:33:51

RGB вообще мало для чего пригоден. Можете попробовать 3+5+10, например. Материалов по композитам Landsat очень много, можно грубо прикинуть соответствие диапазонов и поэкспериментировать. Результат, надо помнить, зависит от времени года и погоды перед моментом съемки, полностью универсальных решений тут нет.

uryevich · 2016-05-04 09:26:05

OverQuantum wrote:

Есть идеи, можно ли какую-то информацию извлечь из таких каналов, сверх RGB из B02+B03+B04?
Можно ли отличить, скажем, заболоченный лес от обычного?

Можно попробовать оттолкнуться от этих комбинаций каналов: http://gis-lab.info/qa/landsat-bandcomb.html
Хоть там и на примере Landsat, но есть ссылка с соотношением канала и длины волны.

wowik · 2016-05-04 14:15:05

Что-то мне стиль карты кажется знакомым.
ChjC60IWUAATnGl.jpg:small
http://twitter.com/JeremyClarkson?cn=Zm … VfcmVjc18y

Announcement

#7526 2016-05-01 08:58:43

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7527 2016-05-01 09:21:26

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7528 2016-05-01 18:00:35

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7529 2016-05-01 22:39:29

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7530 2016-05-02 08:52:34

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7531 2016-05-02 19:12:46

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7532 2016-05-02 19:46:19

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7533 2016-05-02 19:46:45

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7534 2016-05-02 20:25:54

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7535 2016-05-02 22:54:51

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7536 2016-05-03 02:55:56

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7537 2016-05-03 03:32:32

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7538 2016-05-03 08:30:06

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7539 2016-05-03 09:13:16

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7540 2016-05-03 09:41:16

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7541 2016-05-03 10:12:29

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7542 2016-05-03 12:21:50

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7543 2016-05-03 13:18:36

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7544 2016-05-03 14:16:31

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7545 2016-05-03 20:34:21

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7546 2016-05-03 22:15:56

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7547 2016-05-03 22:20:03

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7548 2016-05-03 22:33:51

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7549 2016-05-04 09:26:05

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

#7550 2016-05-04 14:15:05

Re: Добро пожаловать на форум OSM Russia! (оффтоп здесь)

Board footer