Турклуб «Вестра»

Всякого рода геоданные можно хранить в БД в формате WKT.
Выглядит это примерно вот так:
POINT (40 50)
https://arthur-e.github.io/Wicket/

Все это дело поддержано библиотеками, которые умеют WKT читать и писать. Openalayers и Leaflet тоже это умеют.

Если переделать веструвскую БД на хранение WKT, то можно в нее писать еще и траверсы ввиде линий и границы районов в виде полигонов.

В WKT еще есть типы MULTILINE, MULTIPOINT, MULTIPOLYGON - это множественные линии, точки, полигоны и полигоны с дырками.
MULTIPOINT может хранить несколько точек. Например, перевал с несколькими седловинами.

В качестве альтернативы можно хранить geojson

Меня на эту тему больше впечатлила MongoDB, где можно хранить (и искать) GeoJSON.

Геоданные можно хранить и искать не только в MongoDB
PostGIS (Postgress), SpatilaLite (SQLite) и другие умеют на уровне БД выполнять операции с геоданными. Пересечение, объединение и кучу всего еще.
https://en.wikipedia.org/wiki/Spatial_query

Но это уже другой уровень черной магии

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

И вот тут не очень понятно, что это за новый WKT, чем он лучше того же GeoJSON...

slazav писал(а):Может быть. Я, увы, не специалист в правильном хранении геоданных. Понятно, что большой плюс специальных БД - это поиск по координатам, а какой формат лежит внутри - не очень важно, хоть GPX.

И вот тут не очень понятно, что это за новый WKT, чем он лучше того же GeoJSON...

WKT довольно старый. Думаю, даже старше чем JSON. а так в принципе одно и тоже. Только в JSON букв больше и к нему можно добавить информацию о стилях, проекции и кучу всякой метаинформации

slazav писал(а):какой формат лежит внутри - не очень важно, хоть GPX

Важно что можно изобразить с помощью этого формата.

Если только точки - то в базе будет только набор точек: седловина перевала, пик, "центр" плато и т.п.

Если можно добавлять полигоны - можно более точно описать такие объекты, как плато, долины, ледники

Если можно добавлять линии/векторы, то можно:
а) вносить отдельные описания для каждой из сторон перевала, чтобы упростить описание радиальных выходов на перевал, выходов на перевал с последующим траверсом по гребню
б) описать такой перевал, как Дамджайлоо Траверсный (1Б), который состоит из комбинации:
- южного склона перевала Дамджайлоо (2Б),
- северного склона перевала Восточный Дамджайлоо (2А),
- траверса между перевалами Дамджайлоо и Дамджайлоо Восточный через вершину 4731
в) upd: для ленивых и роботов - рисовать векторы сторон перевала и векторы траверсов от перевала по хребту

описание перевала Дамджайлоо Траверсный: http://static.turclubmai.ru/papers/2023/p2.html#z32

Если убрать соответствие регион-перевал из базы, дать возможность указывать регион как полигон на карт и вычислять вхождение перевала в регион геометрически - это решит ряд проблем:
1) "перевал приписан к Кавказу, а находится в Монголии"
2) Можно найти полигоны "не от мира сего" - которые не имеют региона
3) можно добавлять перевалы до регистрации региона, ускорить работу. Потом добавляем регион - и перевалы уже приписаны к нему
4) приписать пачку перевалов к новому подрегиону? Легко - просто добавим новый регион и укажем его полигон.

Единственное - надо запретить создание регионов/подрегионов, которые имеют с другими полигонами частичное пересечение. Полное - можно, отсутствие пересечений - можно, частично - не вижу примера где это может быть.
Озеро/ледник/долина в моём понимании - не подрегион, на них эти ограничения распространяться не должны

Дамджайлоо Траверсный (1Б) нужно объявить траверсом и соответственно хранить в БД как линию.

А для всего, что вы говорите надо ставить PostGIS или SpatiaLite

скорее как три линии: два подъёма на перевал и сам траверс

На мой взгляд, это излишнее усложнение, хотя в терминах WKT что LINE, что MULTILINE без разницы. Фрагменты MULTILINE могут не иметь общих точек

Я просто оставлю это здесь:
https://dev.mysql.com/doc/refman/8.0/en ... tions.html
https://dev.mysql.com/doc/refman/8.0/en ... types.html

Но главный вопрос: кто готов это программировать?
В первую очередь интерфейсы?

А то у меня тоже много гениальных идей:
-- хранить геоданные к отчету и показывать их на схеме
-- показывать на схеме все пройденные и упомянутые в отчете перевалы
-- по списку перевалов и нитке строить приблизительную схему маршрута
-- подсвечивать в нитке непривязанные перевалы

А что именно запрограммировать?
Полно же всяких библиотек для работы с геоданными.
Вот, например, https://github.com/phayes/geoPHP

Интерфейсики. UI.

Добавить кривую, поправить, удалить. Показать.
Где-то у тебя будет схематичная кривая, а у кого-то реальный трек. Его же, наверное, из файлика удобнее прикладывать?
А целиком, или маленький кусочек из файла с треком? Нужен простейший, но редактор трека?

А по уму-то интерфейс каталога надо переделывать в принципе.