Надо же, у меня ровно обратный опыт — в SHP жесткие ограничения на именования полей (латиница, без пробелов, до 30 знаков, если не ошибаюсь), а в SQLite — хоть русскими буквами с пробелами, и без проблем.
устранение сдвига с любой погрешностью благо.
А откуда вы знаете, что к чему надо подтягивать? Какой из источников точнее? Потом на карте с подтянутыми данными будут размещены какие-то объекты, на их основе выпущена какая-то производная документация, и пошло-поехало, концов не найдешь. Повторюсь, для своей задачи вы вольны делать, как посчитаете нужным (особенно, если хорошо понимаете, что делаете), но во вводной статье для новичков я бы не стал давать такие «бест-практисес».
Опять же, значения, которые вы подобрали, подходят для вашего района, в котором вы работаете. В соседнем (а тем более в удаленном) кадастровом районе смещения будут совершенно другими. И если в каждом районе подбирать свои эмпирические коэффициенты, увязать потом все воедино будет совершенно нереально (а то, что у Росреестра у самого данные между районами не сбиты, только усугубит проблему).
как из ПКК получить контур участка на свой слой?
Одно время на ПКК был доступен публичный сервис, позволяющий получать данные по кадастровым участкам в JSON в любой системе координат, но потом эту лавочку прикрыли. В любом случае, такое использование противоречило пользовательскому соглашению, потому что на выписках они деньги зарабатывают.
Так что, думаю, правильный ответ: «законно — никак».
… а потом обнаружить, что в полигонах бывают дырки…
… а потом обнаружить, что попадаются еще MULTIPOLIGON и, не приведи господь, CURVEPOLYGON…
… а потом обнаружить, что длина записи для содержимого ячеек Excel 32767 знаков, а WKT каких-то объектов вылезает далеко за эти пределы…
Не то чтобы решение плохое — сам множество операций делаю в Excel. Просто есть подводные камни )
Если окажется, что штатными средствами имеющихся программ задача не решается, рекомендую посмотреть на библиотеку NetTopologySuite (или JavaTopologySuite, или GEOS — смотря какой язык вам доступнее). Там из WKT-текста легко создать геометрические объекты, с которыми можно делать уже все, что заблагорассудится.
Если говорить про обработку геометрии в БД — то копайте в сторону PosgreSQL + PostGIS, не изобретайте велосипедов самостоятельно.
1. Формат SHP, конечно, по-своему хорош. Хотя бы тем, что он открытый, и его «едят» практически любые ГИС-программы. Но поскольку он весьма древний, есть у него свои ограничения: геометрия только одного типа на слой (либо точки, либо линии, либо полигоны), довольно узкие ограничения по длине наименований, длине значений и количеству полей; часто возможны проблемы с кодировкой текста (особенно, если передавать между разными программами). Плюс обработка SHP-файлов довольно медленная, что для больших объемов может быть критичным. Как альтернативу предлагаю рассмотреть SQLite — он также поддерживается многими программами (хоть и не столь широко) и лишен большинства недостатков SHP. В одном файле SQLite можно собрать сразу несколько слоев (иногда это плюс, иногда минус) и даже организовать связи между ними через внешние ключи.
2. Про географические системы координат — строго говоря, в школе мы не изучали WGS84, т.к. это система координат на конкретном (забугорном) эллипсоиде. То, что изучалось в школе, правильнее назвать LL (Долгота/Широта без привязки к конкретному элипсоиду). Но это мелочь. Гораздо серьезнее то, как вы создали СК, подобрав параметры эмпирическим путем. Вы, конечно, вольны делать, как вам удобно, но рядом надо приписать: НЕ ПОВТОРЯЙТЕ НИ В КОЕМ СЛУЧАЕ! Любая эмпирика в вопросах систем координат неизбежно рано или поздно приводит к тому, что накапливается значительный объем данных, привязанных черт знает как, и который потом кому-то надо пытаться привести в нормальный вид. И если при использовании разных, но известных СК это еще хоть как-то возможно (и то не гарантировано, если в разное время в один источник пишутся данные с разными видами привязки), то в случае таких вот пользовательских, искусственно подогнанных координат, накопленные данные рискуют отправиться в конце концов в мусорку.
А откуда вы знаете, что к чему надо подтягивать? Какой из источников точнее? Потом на карте с подтянутыми данными будут размещены какие-то объекты, на их основе выпущена какая-то производная документация, и пошло-поехало, концов не найдешь. Повторюсь, для своей задачи вы вольны делать, как посчитаете нужным (особенно, если хорошо понимаете, что делаете), но во вводной статье для новичков я бы не стал давать такие «бест-практисес».
Опять же, значения, которые вы подобрали, подходят для вашего района, в котором вы работаете. В соседнем (а тем более в удаленном) кадастровом районе смещения будут совершенно другими. И если в каждом районе подбирать свои эмпирические коэффициенты, увязать потом все воедино будет совершенно нереально (а то, что у Росреестра у самого данные между районами не сбиты, только усугубит проблему).
Одно время на ПКК был доступен публичный сервис, позволяющий получать данные по кадастровым участкам в JSON в любой системе координат, но потом эту лавочку прикрыли. В любом случае, такое использование противоречило пользовательскому соглашению, потому что на выписках они деньги зарабатывают.
Так что, думаю, правильный ответ: «законно — никак».
… а потом обнаружить, что попадаются еще MULTIPOLIGON и, не приведи господь, CURVEPOLYGON…
… а потом обнаружить, что длина записи для содержимого ячеек Excel 32767 знаков, а WKT каких-то объектов вылезает далеко за эти пределы…
Не то чтобы решение плохое — сам множество операций делаю в Excel. Просто есть подводные камни )
Если окажется, что штатными средствами имеющихся программ задача не решается, рекомендую посмотреть на библиотеку NetTopologySuite (или JavaTopologySuite, или GEOS — смотря какой язык вам доступнее). Там из WKT-текста легко создать геометрические объекты, с которыми можно делать уже все, что заблагорассудится.
Если говорить про обработку геометрии в БД — то копайте в сторону PosgreSQL + PostGIS, не изобретайте велосипедов самостоятельно.
Выскажу только пару замечаний/дополнений.
1. Формат SHP, конечно, по-своему хорош. Хотя бы тем, что он открытый, и его «едят» практически любые ГИС-программы. Но поскольку он весьма древний, есть у него свои ограничения: геометрия только одного типа на слой (либо точки, либо линии, либо полигоны), довольно узкие ограничения по длине наименований, длине значений и количеству полей; часто возможны проблемы с кодировкой текста (особенно, если передавать между разными программами). Плюс обработка SHP-файлов довольно медленная, что для больших объемов может быть критичным. Как альтернативу предлагаю рассмотреть SQLite — он также поддерживается многими программами (хоть и не столь широко) и лишен большинства недостатков SHP. В одном файле SQLite можно собрать сразу несколько слоев (иногда это плюс, иногда минус) и даже организовать связи между ними через внешние ключи.
2. Про географические системы координат — строго говоря, в школе мы не изучали WGS84, т.к. это система координат на конкретном (забугорном) эллипсоиде. То, что изучалось в школе, правильнее назвать LL (Долгота/Широта без привязки к конкретному элипсоиду). Но это мелочь. Гораздо серьезнее то, как вы создали СК, подобрав параметры эмпирическим путем. Вы, конечно, вольны делать, как вам удобно, но рядом надо приписать: НЕ ПОВТОРЯЙТЕ НИ В КОЕМ СЛУЧАЕ! Любая эмпирика в вопросах систем координат неизбежно рано или поздно приводит к тому, что накапливается значительный объем данных, привязанных черт знает как, и который потом кому-то надо пытаться привести в нормальный вид. И если при использовании разных, но известных СК это еще хоть как-то возможно (и то не гарантировано, если в разное время в один источник пишутся данные с разными видами привязки), то в случае таких вот пользовательских, искусственно подогнанных координат, накопленные данные рискуют отправиться в конце концов в мусорку.
В остальном — да, неплохой ликбез.