Кадастр

Может быть это и система координат такая, но координаты там похоже в метрах - по крайней мере расстояния между контрольными точками сходятся с точностью до 0.5%.
Пробежался по http://spatialreference.org/, но подходящей системы координат не нашел (

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

Чтобы ответить на этот вопрос, надо знать границы административного района. После муниципальной реформы мне непонятна сущность такого понятия как административный район. Где он используется? Если только в ОКАТО, то где тогда используется ОКАТО? Границы муниципального образования описаны в его уставе, а вот где искать границы административного района, если непонятно как где это понятие сейчас используется?

Чтобы задать систему координат типа CS63 нужны 4 параметра LA0, LO0, X0, Y0 :

+proj=tmerc +lat_0=LA0 +lon_0=LO0 +k=1.000000 +x_0=X0 +y_0=Y0 +ellps=krass +towgs84=33.4,-146.6,-76.3,-0.359,-0.053,0.844,-0.84 +units=m +no_defs

В тех известных EPSG кодах значения X0 и Y0 стандартные, а LA0 и LO0 сдвинуты на “простую” дробь градуса.
На форуме gps-forum.ru было много постингов с координатными парами для Московской области, так что
не должно быть проблем с “теоретическим” вычислением LA0, LO0, X0, Y0 уже по двум известным парам.

Не похоже, а именно в метрах. Там так и написано “неземная система координат, метры”.
На сайте море подобных СК. Например EPSG:2466, EPSG:2554, ну и куча подобных могут быть довольно близкими (если сдвиг добавить).

Сдвиг определяется только изменением X0 и Y0. При таком подходе достаточно знать координаты 1 (!) точки чтобы сделать пересчет
любой другой точки. Не думаю, что создатели местных систем координат такие уж идиоты.

  1. Я сказал могут, а не в самом деле окажутся, например где-то могли взять одну из всеросийских СК и добавить туда эти самые X0, Y0 :wink:
  2. Кроме X0, Y0 может потребоваться Phi
  3. Оптимально найти базовую точку проекции (где плоскость касается сферы), и пересчитывать оттуда. Причем это не 0,0 так как по правилам создания МСК (которых не во всех районах придержитаются) требуется добавить дельту, чтобы все координаты в зоне действия СК была положительными.

    n. Скорее всего даже неправильные параметры перехода от этой СК дадут приемлимую для OSM точность (в пару метров).
    P.S. а еще в МСК могут как-то учитывать кривизну поверхности (не знаю как но упоминание о такой возможности встречал).

Там еще вот такое есть - несмотря на то что растр, векторизовать его можно довольно просто.
Границы областей там по-подробней тех что есть сейчас. Но насчет совпадания границ кадастрового и муниципального деления пока нет, но городские округа там отдельно, а муниципальные районы отдельно.
Ну и опять очередная система координат - хотя тут попроще должно быть.
Оно нам надо?

если б сырые данные получить, то было б неплохо.А векторизировать растр какой смысл…

может кто попросит у админа границы?

Поковырял MIF файлы для московской области, получилось что-то типа:

+proj=tmerc +lat_0=0 +lon_0=38.479571 +k=1 +x_0=3249848.090161 +y_0=-12151.181141 +ellps=bessel +units=m +no_defs (ср .ошибка 12 метров)
+proj=tmerc +lat_0=0 +lon_0=38.482197 +k=1 +x_0=3250017.613303 +y_0=-12900.660956 +ellps=krass +units=m +no_defs (ср. ошибка 16 метров)

Точек 7 штук - искать их очень мучительно оказалось.
Некоторые районы в этих файлах сдвинуты на тысячи км в разные стороны )

Спасибо, посмотрим.
То, что разные районы сдвинуты в разные стороны было очевидно (по координанам).
Кстати, в Тверской области написано:

CoordSys Earth Projection 8, 1001, "m", 1.5, 0, 1, 1250000, 0 Bounds (-6999281.53901, -10002137.4978) (9499281.53901, 10002137.4978)

Что вообще должно быть Земной СК с проекцией “Transverse Mercator”!!!

В порядке эксперимента провел по полученным данным провел границы Сергиево-Посадского и Талдомского районов и совпадающую с ней границу МО, что всяко лучше чем GNS который там был и были НП, которые по карте были во Владимирской области, а на самом деле они в МО. Пока рисовал границы - появились мысли как обозначать, например такой момент, что для way-я границы, которая собирается в relation с type=boundary почти никогда не надо указывать admin_level, так как непонятно к чему он относится.

Мини-конвертер mif2osm собрал, чтобы в JOSM-е смотреть, так что если кому интересно, могу поделится предварительными версиями osm файлов, районов, которых не разметало по вселенной. Готовые есть для Дмитровкого, Талдомского и Сергиево-Посадского, другие можно быстренько сгенерить. Мне кажется оттуда много чего можно будет натаскать в OSM - у меня прилегающая к даче территория очень не дурно легла.

Ну и появился скриптик, который симлексами подбирает параметры проекции для proj4 - может пригодится в твери.
Хотя если честно, я совсем недавно узнал про всякие проекции, и не совсем понял, что нам даст, тот факт, что там написано, что это земная СК )

Естественно все на горячо любимом нами perl-е.

Вообще-то можно указываеть максимальный (т.е. минимальное число) уровень границы. Например для куска границы НП, совпадающей с границей области указывать “admin_level=4”, и т.д., поскольку мало кто по гос.границе еще ведет границу соответсвующего района. Тогда и простым рендерерам (которые не смотрят на отношения) будет полегче они просто проведут нужную в данном месте границу.

А на сам конвертер (и скриптик) посмотреть нельзя?

По идее это должно дать отсутствие надобности в подобных скриптах. Т.е. здесь имеет быть проекция с известными параметрами перехода в тот же WGS-84, в отличии от МСК, где ключи перехода лежат с 1-ых отделах и, скорее всего, тем, кто хочет иметь дело с OSM, их лучше не видеть.
К сожалению мои попытки запустить “ogr2ogr -t_srs “EPSG:4326” out Query1.MIF” дали что-то “размазанное по вселенной”. Или шапка файла не соответсвует действительности, или данные 1001-ого датума беруться неизвестно откуда, или, что наверняка и происходит, я не умею готовить огров.

Кстати, погрешность порядка 10-м вполне соответсвует точности бытовых GPS (+точности установки точек…) и точности данных в OSM (что, к тому же, неплохо соотносится с параноидальными устремлениями нашего государства). Отсюда же следует непригодность импорта данных из OSM в кадастры и прочие серьезные БД, где требуется субметромая точность .

Да, полностью согласен. Сам потом включил голову и к такому-же выводу пришел. (right|left):region предлагаю заполнять в виде: “Московская область, Шатурский район” записывая туда четные уровни из admin_level. Кстати простановку и *:region и admin_level для вэя границы можно поручить боту. Я так понял admin_level нужен всем рендерам ).

http://nopaste.info/b54dd43960.html

./mif2osm --file ../cadastr/50/group/X05-0.MIF --proj "+proj=tmerc +lat_0=0 +lon_0=38.479596 +k=1 +x_0=3249849.890208 +y_0=-12150.598631 +ellps=bessel +units=m +no_defs" > ~/tmp/05.osm

Ну тогда подберем, если надо будет.

У меня закрадывается подозрение, что у yahoо местами ошибка привязки метров 20-25 - в чистом поле треки лежат кучно, но на дорогу по снимку не попадают. Попробую сделать контрольные точки не по снимку, а по osm карте. То что есть у меня сейчас лучше ложится на яховские снимки, нежели на osm карту.

У снимков что, Yahoo, что google, имеется примерно подобрая погрешность. Причем она плавает от точки к точке. Подозреваю, что это погрешность орторектификации. Когда снимок, полученный под углом к нормали, разворачивают в прямоугольный, то приходится учитывать рельеф (точки с разной высотой отклоняются в стороны по разному), и при не очень точной 3-d модели поверхности получаются разные погрешности (посмотри насколько крыши домов отъезжают от фундамента).

В проге надо поменять regexpr по которому отлавливаются координаты, чтобы понимались отрицательные значения:

--- mif2osm.orig<------>2009-07-13 19:39:00.000000000 +0400
+++ mif2osm<--->2009-07-13 19:39:27.000000000 +0400
@@ -53,7 +53,7 @@
         };
         
     };
-    if ( /^\s*([\d\.]+)\s+([\d\.]+)\s*$/) {
+    if ( /^\s*(\-?[\d\.]+)\s+(\-?[\d\.]+)\s*$/) {
         # нашли пару координат
         $id++;
         my ($lat, $lon) = $proj->inverse($1, $2);

Попробовал погонять на Химках, что-то вроде:

+proj=tmerc +lat_0=55.66709 +lon_0=37.49825 +k=1 +x_0=0.0 +y_0=0.0 +ellps=bessel +units=m +no_defs
  1. Это действительно квартала (границы приходятся почти по всем улицам).
  2. Притянуть то что получается точнее десятка (а то и поболее) метров затруднительно (причем систем трудноуловима, погрешность не нарастает от одной точки к другой, а плавает для не очень удаленных мест). Скорее всего границы проходят не по осевым дорог (границы округа описываюся как “четная сторона улицы”, “северная сторона землеотвода” …), а знаки границ нп могут приходится на границу, которая почти касательна к дороге, а то и вообще в десятках метров от этой границы.
    Или же просто в росимуществе не очень точно эти координаты посчитали (а то и попортили при публикации). В любом случае такие границы будут куда точнее, чем то что сейчас есть (где оно есть).

Попробовал преобразовать с теми же параметрами, что и Химки, Долгопрудный:
Граница местами идет впритирку (в пределах десяти метров), а местами образует дыры и перехлесты по нестолько сот метров (например выступы границ в противоположные стороны).
Похоже, что границы между районами никто не согласовывал.
Опять же это говорит о точности данных.

За патчик спасибо ) - не сразу столкнулся с отрицательными координатами в mif.
По МО у меня получилось три группы карт, у каждой из которых своя КС:

1: 01 04 05 09 11 12 13 16 20 21 22 23 24 25 27 28 29 31 34 39 41 49 53 62
2: 02 03 06 08 18 26
3: 07 10 14 15 17 17 19 32 36 36 40 42 43 44 45 46 47 48 52 54 55 56 57 58 59 60 61 64 65

Переход для первой я приводил, для третьей я так понимаю ты подобрал. Для второй у меня есть предварительный вариант - в нем границы между районами тоже прослеживаются, и тоже неплохо согласуются с районами из группы 1.
Думаю как допилить скриптик, чтобы он не полигоны рисовал, а линии между нодами с 3-мя и более линками - тогда границы можно довольно просто перенести будет - объединил сегменты и готово, а плагин для упрощения линий в josm был какой-то вроде.
С границей москвы, которая отрисована сейчас эти данные согласуются неплохо, хотя есть ряд очень спорных моментов.

Там я подбирал без всяких симплексов, чтобы линии легли не сильно далеко от дорог :wink:
Ну и стоит оценить, как лягут районы подальше от Химок.

Скорее всего прокатит. В любом случае это будет лучше, чем ничего.

Во первых сама граница Москвы довольно спорная (видел участкми где она заметно цепляет куски чужих улиц). Во вторых еще раз рекомендую посмотреть на границу Химок и Долгопрудного - там этих спорным моментов пол-границы.

Это зоны (1000км = 1000000 м) судя по вашему +x_0 трехградусная зона=3 с центром 250000
а +y_0 похоже на +lat_0=0.1
Вообще я бы еще добавил к +ellps=krass и +towgs84= как в формуле выше