Редактор ВОЛС

[pavlabor 1 939]

В 28.02.2021 в 10:04, a_n_h сказав:

ага, уже открывал!?

  А если по сути, смотрел через Notepad++, я надеялся, что можно как-то увидеть схему. В png экспортируется схема полностью?

Mozilla-ой, показывает структуру.

[pavlabor 1 939]

3 часа назад, dead сказав:

Я не хочу далеко отходить  от  придуманной концепции. А именно хочу чтобы все объекты на схеме привязывались к карте, а не наоборот. Можно сделать чтоб на схеме  был еще один режим отображения всех проходящих точек. По дефолту он был бы выключен.

Если по взрослому, то опта не может висеть в воздухе, это или канашка, или опоры и это разные сооружения.

По логике сначала строится инфраструктура, потом монтаж кабелей.

 

Не могу подключить в доме ону-коммутатор.

 

В дом заходит кабель, разварен делитель 95/5, 95% уходит на другой дом, 5% на ONU V2808, дальше клиенты подключены медью.

Перебрал много вариантов, не стыкуется.

[dead 93]

В 08.03.2021 в 20:27, pavlabor сказал:

В дом заходит кабель, разварен делитель 95/5, 95% уходит на другой дом, 5% на ONU V2808, дальше клиенты подключены медью.

Перебрал много вариантов, не стыкуется.

 

Ну ты бы привел то, что у тебя получилось и обозначил, что не получается Т.к мы ушли от понятия коммутатор, рама и т.д., можно создать любого гибрида, в котором можно использовать любое количество:
1) коннекторов. К коннектору подлючается одно волокно, дальше идет пачкорд либо к другому коннектору, либо порту

2) паек. В пайку входит два волокна

3) сплиттер. Сплитер с точки зрения логики редактора ВОЛС это куча пачкордов между одним коннектором и другими

4) портов. К порту может идти только патчкорд. 

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

Відредаговано 2021-03-09 21:02:55 dead

[dead 93]

P.S. увидел, что это было заблокировано. Разблокировал

[pavlabor 1 939]

В узел дома с малой плотностью абонентов входит кабель.

Кабель линкуется со сплитером.

Сплитер не линкуется с ОНУ(коммутатором).

Поставив рамку, сплитер не линкуется с рамкой ни на порт, ни на спайку.

Пришлось поставить промежуточный кабель, через который удалось слинковать сплитер на рамку, а дальше на ОНУ(коммутатор).

 

Я считаю что хвост сплитера это такое же волокно как и волокно кабеля, и логично сделать чтобы сплитер линковаллся сразу на рамку(без кабеля для линковки).

Проект https://all-optic.com/cgi-bin/stat.pl?a=u_main&gid=IwXcy0qSj3Ao2DtOiOgEUA#

 

Еще один момент.

Оптический модуль (порт) может иметь как одно волокно, так и два, а при конвертации QSFP+ в 4хSFP+ требуется 8 волокон на один порт QSFP+.

Но в редакторе, на условный порт коммутатора можно подключить только одно волокно.

 

Відредаговано 2021-03-10 07:19:02 pavlabor

[pavlabor 1 939]

del

Відредаговано 2021-03-10 15:50:21 pavlabor

[WideAreaNetwork 222]

В 28.02.2021 в 18:04, WideAreaNetwork сказав:

есть ли возможность просмотреть путь волокна задав только начало пути? чтобы показало до первого обрыва

@dead

[dead 93]

22 минуты назад, WideAreaNetwork сказал:

@dead

пока не занимался этим вопросом. Может в перспективе

[pavlabor 1 939]

После сегодняшней ночи перестала корректно работать кодировка!

 

Еще одно замечание.

Если єто чистій редактор ВОЛС, то все окей, НО - такой редактор наверно мало кого устроит, разве ЕТТ и то с натяжкой.

Требуется редактор построения телекоммуникационных сетей и рано или поздно будут возникать вопросы как слинковать то, сьо.

Вот возник очередной вопрос.

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

В данном сегменте задействованы по: модуль ПОН+блок питания > спец кабель с медью > ОНУ+радиоудленитель.

Предложение следующее.

Создать УНИВЕРСАЛЬНЫЙ объект (и возможно элемент порт, спайка, маркер) который можно линковать с чем попало и как попало, устанавливать любые аватарки (ОНУ-шка, ОНУ-коммутатор, Wi-Fi роутер, блок питания РоЕ и т.д.)

Если ввести маркер, то в свиче можно поменять порт на маркер и на него слинковать два(или ? волокон.

 

Еще один момент, при перетаскивании мышкой, перемещается вся схема, при перетаскивании мышкой внутри контейнера, перетаскивается контейнер, в результате если не заметил, то все в контейнере перемешивается и требует востановления. Дал ссылку посмотреть другому человеку, он говорит "нечего не делал", но два часа ушло чтобы восстанавливать размещения связей. Возможный вариант - блокировать контейнер.

[WideAreaNetwork 222]

11 часов назад, dead сказав:

Может в перспективе

нужная вещь, одно дело пара десятков волокон, а если их сотни? тысячи и более?

[pavlabor 1 939]

В 08.03.2021 в 09:20, pavlabor сказав:

На карте идет привязка только узлов, как следствие, иногда кабель проходит в обход, может и несколько километров (мост через речку) но на карте кабель идет не через мост, а через речку.

Можно реализовать путем создания "узла", но такой узел сильно загромождает карту

Есть предложение создать "объект инфраструктуры" колодец, столб, труба, угол здания...

Через такой узел кабеля могут идти как транзитом, так и иметь муфту, в таком случае можно изменить статус узла "объект инфраструктуры" или "Узел телекоммуникации".

Если на "Узеле телекоммуникации" указать группу владельцев "Укртелеком", "Облэнерго", "Кооператив виктория", то появится возможность строить сети телекоммуникаций с группировкой по категориям (кабельная канализация - канашка, опоры электропередач- воздушка).

Прикрути яркость на мониторе

Там же можно выставить "режим".

Оказывается что эта фича уже реализована

В 27.09.2020 в 15:12, dead сказав:

Многие просили интеграцию с картами. В видео вы это увидите, но озвочу еще раз:

• схема - это логические соединения объектов, она удобна для анализа, проектирования, понимания ситуации и т.д. Это и есть редактор ВОЛЗ, который я постоянно тут демонстрировал
• карта - она для физического положения объектов. Есть соотвествие между схемой и картой в соединениях и элементах. Но не в позиции. На схеме вы можете колодцы выстроить в одну линию чтоб не мешались, а на карте именно так где они физически. 

Я видел попытки изобразисть в ВОЛС физические схемы. Реально пришлось форсировать интеграцию с картами ибо вы пошли не туда. На видее, конечно, не все. Только основной принцип. Будет еще клик по объекту на карте с переходом к фрагменту на схеме

 

 

[dead 93]

Улучшил работу с картой. Видео надо посмотреть внимательно:

 

P.S. Фича пока не доделана  до идеала

Т.е пока не надо гвоорить, что при изменении кабеля временно появляются контейнеры, которые должны выводиться только в режиме  "инфраструктура"

[Darth Vader2 33]

Не мог пройти мимо, чтобы не похвалить. Дед - молодец. Просто отлично.

[dead 93]

Как и обещал:

optic.txt

В optic.txt структура бд. Теперь все данные могут храниться в вашей базе данных.

 

Еще я планирую сделать небольшой сервер на питоне или перле, который сможет доставать данные из этой БД, чтобы была полная автономность. Для просмотра. Изменение через мой сервер

P.S. База данных mysql

[pavlabor 1 939]

В 14.03.2021 в 14:24, dead сказав:

Улучшил работу с картой. Видео надо посмотреть внимательно:

 

P.S. Фича пока не доделана  до идеала

Т.е пока не надо гвоорить, что при изменении кабеля временно появляются контейнеры, которые должны выводиться только в режиме  "инфраструктура"

Я так понял "Ифраструктура" это еще один из режимов просмотра.

У кого есть желание, предлагаю покурить такую визуализацию,

https://cytoscape.org/cytoscape.js-tutorial-demo/

Визуализация живая и динамичная, позволяет датализировать смещать и докапыватся до нужной инфы, строить алгоритмы отрисовки трассы (как пример, режим "Run algorithm").

Есть плагины конвертации данных в формате JSON, инкапсуляции контейнеров.

 

[pavlabor 1 939]

В редакторе идут роботы и понятно что их вагон.

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

 

Проблема 001 - общая работа с документом.

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

И если над схемой работает тех отдел, а в этот момент схемой пользуется мастер разваривающий муфту, то не исключено что мастер может случайно изменить схему и после авто сохранения получим не определенный результат. А после разварки/переварки, мастеру, по любому нужно внести изменения схему.

Решение следующее.

Редактор позволяет создавать локальный бекап.

Тех отдел работает над основной версией схемы, а сварщику выдается локальный бекап.

Сварщик открывает в редакторе персональный профиль, создает схему и импортирует в него бекап.

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

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

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

 

Рекомендации к разработчику. Нету.

 

Следующую проблему и способы ее минимизации опубликую позже.

Відредаговано 2021-03-30 04:09:26 pavlabor

[dead 93]

Сделал фичу. Это пока тестовый вариант. Возможно многим будет в тему. Если да, то добь ее до конца

 

[pavlabor 1 939]

Да ты реально силач!

Для печати вообще - проблема закрыта!

Но тут еще одна проблема которую данная фича не решает,

это - первичная загрузка документа.

В перспективе, проект может разрастаться до такого размера, когда его будет просто изначально невозможно загрузить в редактор.

Возникает вопросик, что будет, когда изменится размер редактируемой зоны внутри крупной схемы, с выделением группы объектов не все так просто (напрашивается управление выделением по Ctrl).

Нужно юзать, а бока сами вылезут.

 

Давай когда пофиксиш бекап,

я попробую сделать и выложить реальные примеры работы с масштабируемыми схемами.

Потому как идея идеей, а в реале могут полезть другие косяки.

 

ps. ===========8<---------------

По коммерциализации проекта.

Думаю что тебе все таки нужно сделать модуль для локальной работы.

Людей это успокоит, они начнут его портировать к своим билингам и знать что потраченное время не пропало даром.

А зарабатывать можно на следующих этапах.

1. Софт с функцией редактирования все равно оставляешь на сайте. Во первых, он будет дорабатываться и постоянно увеличивать актуальность. Писать каждому свое, это гораздо дороже, чем платить абонку например 10 баксов в год на средних проектах(сеть 1000-2000 пользователей) и 50 на крупных (сеть больше 2000 пользователей), за такие деньги програмера не найдешь.

2. Можно посадить своих проектантов, вести сопровождение гарантировать бекапы.

3. Сделать возможнось подключать библиотеку объектов, в таком случае у тебя будут разводить электрические, водопроводные, отопительные и другие сети. А тебе пофиг - платите деньги.

 

Главное не падай духом!

Відредаговано 2021-04-02 04:32:51 pavlabor

[pavlabor 1 939]

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

Результат.

https://all-optic.com/cgi-bin/stat.pl?a=u_main&gid=IwXcy0qSj3Ao2DtOiOgEUA

 

Вырезал сектор и сохранил отдельным бекапом, что есть нереальный ГУД!

https://all-optic.com/cgi-bin/stat.pl?gid=XOMfvU14DXXMNbXJZAWLA&a=u_main#

За баг что кабеля вывались с контейнера, я уже писал.

Попробовал импортировать в картинку... не импортировалось, по все вероятности картинка все равно получается большой.

Отсюда, разводку оптики, например в датацентре нужно разводить как отдельная схему, а печатать как как отдельные шкафы, муфты, касеты.

Но по ресурсам получается дико маловато. Такой узел при разводке по любому нужно видеть весь. Проблема в сложности в такой схеме выделить какой то объект для печати.

Итог - по печати вопрос остался открытым, нужно думать.

 

Это не баг, использую как линейку для выравнивания элементов.

Відредаговано 2021-04-02 06:22:29 pavlabor

[dead 93]

Оказалось, что редактором ВОЛЗ пользуются довольно большие сети, у которых много тысячи оптических объектов. Пришлось для громадных схем создать альтернативный вариант просмотра

 

[dead 93]

P.S. Я подумал, что из видео не свосем  понятно, почему схема большая. Там один большой фрагмент схемы наложен на другой несколько раз, чтобы получить много объектов ибо полностью настоящую схему чужой сети я не могу выложить.

[pavlabor 1 939]

Шаг вперед.

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

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

3. При увеличении схемы, показывать карту

 

А вообще, начинаться все должно - с корректного бекапа.

Ну и очень не хватает кнопки включения режима редактирования.

[dead 93]

Менять режим отображения в зависимости от масштабирования идея хорошая. Но не все так просто. Тут есть такие проблемы:
1) мы увеличиваем масштаб и в определенный момент должны подгрузить детальную схему. А у меня тут схемы, как я сказал, под 200 тысяч элементов. Они банально будут грузиться и строиться несколько секунд. Но это небольшая проблема. А вот серьезная заключается:
2) даже если браузер прорисовует маленький кусочек громадной схемы, он все равно зараза тупит
Поэтому при увеличении масштаба надо все равно схему обрезать. Ну, допустим я обрежу с запасом, скажем умножив ширину и высоту фрагмента на 3. Тогда мы сможем его перемещать по экрану. Но тогда некоторым это может не понравиться если они захотят скользить по схеме далеко. В частности если включат фичу трасировки пути. В общем надо давать разные варианты. И при этом не перегружать интерфейс.
Насчет режима ридонли/редактирование согласен

[pavlabor 1 939]

 

12 часов назад, dead сказав:

Тут есть такие проблемы:
1) мы увеличиваем масштаб и в определенный момент должны подгрузить детальную схему. А у меня тут схемы, как я сказал, под 200 тысяч элементов. Они банально будут грузиться и строиться несколько секунд. Но это небольшая проблема. А вот серьезная заключается:

Есть время на загрузку данных, есть время на отрисовку схемы.

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

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

 

12 часов назад, dead сказав:

2) даже если браузер прорисовует маленький кусочек громадной схемы, он все равно зараза тупит
Поэтому при увеличении масштаба надо все равно схему обрезать. Ну, допустим я обрежу с запасом, скажем умножив ширину и высоту фрагмента на 3. Тогда мы сможем его перемещать по экрану. Но тогда некоторым это может не понравиться если они захотят скользить по схеме далеко. В частности если включат фичу трасировки пути. В общем надо давать разные варианты. И при этом не перегружать интерфейс.

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

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

1. магистральная схема по странам,

2. магистральная схема по областям,

3. магистральная схема по районам,

4. локальная схема сети,

5. детальная схема сети,
6. детальная схема сектора сети.

Примеры визуализациия тебе сбрасывал.

Для построения этих схем нужно перегружать данные.

 

Отсюда придется реализовать:

1. Сохранение в данных идентификатора схемы (если идентификатор в базе существует, все объекты перезаписываются поверх старых (не спорю, напряжно!))

2. URL-ы для перехода на схемах. При изменении масштаба меняется общая отрисовка, при клике на район, схема отрисовывается со смещением центра в точку клика.

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

 

Например имеем такую схему района, она отрисовывается только узлами, кликаем на узел и открывается детализация.

Это - 3. магистральная схема по районам.

 

Вот открылась 4. локальная схема сети.

 

Выбираем показать 5. детальная схема сети.

Далее мы можем открыть 6. детальная схема сектора сети.

Это уже схема подключение конечных пользователей.

Нагрузка должна упасть на порядок, что позволит отражать данные так

И даже так

 

Все схемы имеют одинаковый идентификатор, поэтому при изменении данных, в базе редактируются только те объекты которые отражаются в данной схеме, без нарушения целостности всей схемы.

При построении маршрутов от точки "А" до точки "Б", данные о маршруте могут передаваться в куках.

 

Прикинь, чтобы все это реализовать нужно доработать всего два пункта!

1. Сохранение в данных идентификатора схемы (если идентификатор в базе существует, все объекты перезаписываются поверх старых (не спорю, напряжно!))
 2. URL-ы для перехода на схемах. При изменении масштаба меняется общая отрисовка, при клике на район, схема отрисовывается со смещением центра в точку клика.

 

PS.

12 часов назад, dead сказав:

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

Потому что за кадром, браузер рисует всю схему!

 

Відредаговано 2021-05-20 06:16:29 pavlabor

[dead 93]

Цитата

 

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

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

 

Не всегда так рационально делать. Например, google map так не делает)
В моем случае также нерационально по двум причинам:
1) та схема, которую мне предоставлили, реально громадная. Как я уже сказал там под 200к соединений на детализированной схеме. Если ее загрузить полностью, то это большой объем данных
2) если с первым пунктом можно поспорить, то основная причина в том, что схема меняется. И она может меняться параллельно. При хранении схемы в js она может быть неактуальной. Сейчас при любом несоответсвии подгружается тот фрагмент, который сейчас на экране. Да и вообще, у тебя на бумаге все очень просто. Тебе реально надо в менеджеры идти) Ты говоришь "это не трудно", но не предсставляешь сколько нюансов возникает при создании даже маленькой функциональности. То, что это не так и просто говорит то, что я таких редакторов как у меня и близко не видел)

В общем я сделал подгрузку при масштабировании и панорамировании. Работает это так:

 

 

Понятно, что слегка дерганно (кстати это в хроме на маке, а в винде на том же хроме меньше дерганий), но это реально большая и очень плотная схема (там человек вместо объединения рам в контейнер, просто рисовал вплотную друг к другу). На среднестатистической схеме такого не будет.