SteepZero

Вы упомянули постгис, соответственно нужно использовать его формат geom через st_makeline(). Ну или geojson в постгресовских jsonb полях.
Это оптимальные варианты. Второй предпочтительнее для быстрой отдачи клиентам, а первый для фильтрации или обработки в постгисе. Так как истинный геоджсон может содержать несколько геометрий и надо писать кастомную функцию для преобразования в постгисовскую геометрию, я бы хранил и обрабатывал в постгисе, а в геоджсон или другой нужный формат преобразовывал бы опосля

Хранить точки отдельно - дрочево при достаточно большом количестве точек. Да и сами точки без трека никакой полезной информации не несут ведь.

>не нравится как он написан
пффф а ты что думал, в сказку попал? тебе и не должно нравиться, это для бизнеса где-то на 25 месте находится.
-----
чесно говоря я вообще не слышал чтоб реально на практике УМЛ использовали, для проектирования (хотя тема когда-то и была на хайпе).
Ну да на черновиках набрасывают общие идеи, сам код также может быть тем черновиком для идей, но это всего-лишь черновик.
=======
>"Давай декомпозируем на задачи и начнем делать. По ходу реализации разберемся"
очень грамотный, взвешенный подход. Основная проблема не опытных людей, попытка сразу выдать идеальный результат в вакууме, люди которые поопытнее знают что это сделать не возможно, а попытка идеальной проектировки приведет только к переусложнению и ухудшит разработку и вместо того чтоб гибко подгонять решение под постепенные уточнения, вы будете стремится все подогнать под рамки какой-то первой "идеальной" идеи реализации, на основе первого восприятия задачи (которое часто ошибочно).

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

https://developers.google.com/image-search/v1/json... мабуть кому-нибудь пригодится.

Используйте Omnipay, под него имеются официальные драйвера Яндекс.Кассы и Робокассы, а так же шлюзы для тысяч других платежных систем.
API универсальное, достаточно написать код один раз и в дальнейшем просто цеплять различные драйвера на момент оплаты.

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

Ну и второй момент - Laravel - это всё же фреймворк, со всеми вытекающими, далеко не каждый стремиться выложить свой "крупный" проект на базе Laravel для всеобщего обозрения...

Но, давайте попробую угадать... Это (ссылка на сайт оригинал у меня чего-то не открывается, ссылка на гитхаб - внизу страницы) подходит под Ваше определение "крупного" проекта?

В самой команде пропишите ключ --timeout=0, иначе у artisan команды истечёт время выполнения, как в вашем случае

Если в руки попал настоящий полноценный .p12 с известным паролем или даже незапароленные *.crt и *.key - можно выдавать себя за владельца сертификата и ни одна собака не докажет, что это не он.
Но Вам в руки попало то, что раздается всем подряд совершенно бесплатно типа рекламной листовки - общий ключ (публичный сертификат) в формате DER. Key Usage практически значения не имеет, интересен мог быть Extended Key Usage - вот там обычно перечисляется его настоящая применимость.

Так что Вы можете на него полюбоваться. И все :)

composer create-project username/mypackage path --repository-url=repo.yourcomposerrepo.com

На СЕО это положительно скажется, но прежде всего легче будет людям, так как более понятный, тн человекопонятный URL.
Но только по фильтрам лучше не сокращать, а выводить все.
Ну те в вашем случае:
metro1 - na-dom - Это один параметр разные значение
site.ru/catalog/category1/metro1 - категория и метро
site.ru/catalog/category10/metro1/male - категория, метро и женский пол
site.ru/catalog/category10/metro1/any/ - категория, метро, любой пол
site.ru/catalog/category10/na-dom/male/- категория, выезд на дом, женский
site.ru/catalog/?sort_reviews=ASC&sort_price=DESC - просто сортировка по отзывам и цене, сортировки все же лучше делать отдельно, через классический GET. , его же любым выше можешь добавлять
По факту все эти урлы - GET запросы, просто они прячутся под url.

Route::get('/catalog/{category_name?}/{tip_vyezda?}/{sex?}/', 'FrontController@showCatalog')->name('show.Catalog');

/*Где то в FrontController*/

public function showCatalog() {
$category_name = request()->category_name;
//и тд, обработчик проверки и прочее
}

А проверить валидатором на уникальность никак? Это же проще, чем городить костыли.

Потому что webroot надо было на public ставить, а не на корень сайта.

htaccess, nginx configs