@NKomissar
Посмотрите в сторону QGIS.
Вообще, растровая карта будет “тяжелой”. Поищите векторную библиотеку.
Здравствуйте! Пишу в качестве учебного проекта парсер сайта stat.gibdd.ru и в процессе захотелось нанести геоданные оттуда на карту,а именно оценить аварийность на трассах федерального значения. Однако,возникла проблема с получением геометрий автодорог федерального значения. Изначально брал данные отсюда https://wiki.openstreetmap.org/wiki/RU:Россия/Автодороги и с помощью Overpass API экспортировал в формате GeoJSON. Однако,они не очень содержательны и все являются Linestring’ами или MultLineString’ами. Возможно ли где-то найти более подробные отрисовки?Спасибо!
А какие подробности интересуют?
Добрый день! Например, Трасса М7 “Волга” . К сожалению, в качестве объектов обозначены только тонкие полоски посередине, а не полосы полностью
а в чем проблема переделать в нужное ??
Как конвертировать подробную карту нужно области в pdf? Каким софтом воспользоваться? Нужны бумажные карты со всеми тропами
Благодарю!
Вчера погуглил и нашел еще один чудесный сервис. Возможно будет полезен для путешественников, кто собирается на дальняки с бумажными картами. https://nakarte.me/
Кучу разных слоев + возможность экспорта в пдф нужных.
Есть набор данных с координатами “в проекции Гаусса-Крюгера в ГСК-2011”
Пример: “6089310.083476149”,“15412213.750192378”
Как это запихнуть в geography postgis’a?
Есть набор данных с координатами “в проекции Гаусса-Крюгера в ГСК-2011”
Пример: “6089310.083476149”,“15412213.750192378”
Как это запихнуть в geography postgis’a?
Geography(ST_Transform(geom,4326))
Стоило уточнить, что с PostgreSQL я знаком всего несколько часов…
update mvd set location = Geography(ST_Transform(ST_Point(lon, lat), 4326))
> ОШИБКА: ST_Transform: Input geometry has unknown (0) SRID
update mvd set location = Geography(ST_SetSRID(ST_Point(lon, lat), 4326))
> Coordinate values were coerced into range [-180 -90, 180 90] for GEOGRAPHY
Сначала нужно создать геометрию из XY, потом назначить ей правильную СК и только затем уже трансформировать в другую СК.
Стоило уточнить, что с PostgreSQL я знаком всего несколько часов…
update mvd set location = Geography(ST_Transform(ST_Point(lon, lat), 4326)) > ОШИБКА: ST_Transform: Input geometry has unknown (0) SRID
update mvd set location = Geography(ST_SetSRID(ST_Point(lon, lat), 4326)) > Coordinate values were coerced into range [-180 -90, 180 90] for GEOGRAPHY
Правильно ругается.
В первом случае она не знает из какой системы координат трансформировать, а во втором вы просто явно присвоили принудительно 4326 (географическая система координат), без выполнения преобразования.
Чтобы сработал ST_Transform - геометрия должна быть создана с правильным SRID.
Если у вас данные в “в проекции Гаусса-Крюгера в ГСК-2011”, вам нужно сначала определиться с нужным SRID для неё (или возможно создать её, если среди штатного набора не найдётся подходящей) и затем выполнить конвертацию.
Либо другой вариант - ещё до загрузки в БД выполнить конвертацию в 4326 при помощи других средств (например gdal), а потом уже грузить в базу без лишних преобразований. Но в любом случае надо сначала узнать точные параметры исходной проекции, иначе преобразование будет невозможно выполнить корректно при помощи любых средств.
update mvd set location = ST_Transform(ST_SetSRID(ST_Point(lon, lat), 7683), 4326)
Такое заклинание тоже не сработало
Нашёл относительно понятную программу для преобразования координат, но в ней очень криво реализован импорт csv да и получившиеся координаты уплывают метров на 100 к северу
Такое заклинание тоже не сработало
И не должно.
SRID 7683 (оно же EPSG:7683) - это просто ГСК-2011, т.е. опять же географические координаты (широта/долгота в градусах). А у тебя вместо него “в проекции Гаусса-Крюгера в ГСК-2011”, т.е. X/Y в метрах.
Надо от исходных метров перейти к градусам. А для этого надо знать параметры проекции. Потому как вариаций “проекции Гаусса-Крюгера” великое множество, на том же EPSG зарегистрировано больше тысячи вариантов UTM-проекций (проекция очень похожая на Гаусса-Крюгера, но немного отличающаяся параметрами) и это только западные стандартные, а нестандартных вообще бесконечное кол-во.
получившиеся координаты уплывают метров на 100 к северу
А это скорей всего из-за различий в датумах (дополнительных параметров проекции). В общем - обратись к тем, кто дал тебе эти данные и попроси полные параметры проекции. Без этого точно сконвертировать не получится.
Данные отсюда. Вероятно предполагается, что эти параметры стандартные и всем известны.
В общем ну его нафиг. Пойду домики рисовать…
Данные отсюда. Вероятно предполагается, что эти параметры стандартные и всем известны.
НКВД как всегда бежит впереди паравоза. В чем проблема перевести CSV с помощью
ogr2ogr в человеческий GPX и работать с ним?
В чем проблема перевести CSV с помощью
ogr2ogr в человеческий GPX и работать с ним?
У этой программы ~50 параметров с описанием на эльфийском. Для людей, у которых в нике нет слова gis, это непреодолимое препятствие.
У этой программы ~50 параметров с описанием на эльфийском. Для людей, у которых в нике нет слова gis, это непреодолимое препятствие.
Это то полбеды, параметры подсказать можно для типовых сценариев.
Самое главное (как я уже и писал) - параметры проекции.
Ни postgis, ни ogr2ogr, ни любая другая программа не сможет сама сконвертировать данные в неизвестной ей проекции, а за рубежом обычно используют UTM вместо Гаусса-Крюгера.
В принципе есть стандарт на проекцию Гаусса-Крюгера (ГОСТ 32453-2017), но судя по тому что у вас после конвертации в программе, поддерживающей этот стандарт координаты отлетели на 100 метров от нужного места - координаты в наборе не вполне соответствуют этому стандарту. Например они легко могли использовать проекцию Гаусса-Крюгера в другом датуме (СК-42 или СК-95) (т.к. для того, кто выкладывал данные это тоже китайская грамота). В итоге нужно или перебирать возможные варианты или пробовать вычислить параметры самому по известным контрольным точкам.
Я пересчитал одну точку в СПб, и она на 100 метров южнее чем надо.
Если это везде так, то надо добавить эти 100 метров и не ломать голову.