Топорный вариант в лоб, делаете UNION всех трёх запросов от разных прав, где вместо недоступных полей вставляете хоть NULL, хоть в доступе отказано.
Более красивый вариант, у вас есть три вьюшки аля ViewProductByAdmin, которая если прав не хватает возвращает кукишь, а выбор вьюшки уже лежит на клиенте.
Осваивайте операцию Buffer - и будет понятно, рядом маршруты проходят или нет.
С противоположным направлением вообще не понял в чём сложность. Если ты должен загрузить попутку на 65%, а выгрузить на 30%, то очевидно что не получится.
Группировать нужно перед джойном. Используйте FROM SELECT.
А так у вас получается, что в run и ride по одной строке и всё хорошо (у вас вышла 1 строка), но в swim выдаст 5 строк. Но в этих четырёх строках для run и ride будут не нули, а какое-то случайное значение из их предыдущих строк, поэтому суммы у вас и не совпадают.
В документации чётко написано, проекции у геометрий должны быть заданы, т.е. ST_SetSRID, плюс они должны быть одинаковы. А у вас одна WGS84, а другая (по-умолчанию) PseudoMercator.
1) отредактировать свою переменную окружения PATH, вырезав от туда хлам;
2) Использовать для запуска полный путь: C:\Program Files\PostgreSQL\10\bin\psql
ПС. Что за молодёжь пошла, шаг влево от инструкции и всё пропало, надо уже дописывать в последний пункт - выкинуть компьютер.
1) SELECT ... LIMIT 100 OFFSET 300
2) Это добавит тормозов, т.к. базе придётся прочитать все миллион строк и отсортировать их. Если это не критично, то не стоит.
3) Это как?
OSM это сырые данные - это просто нужно принять как факт. Для конечного пользователя их нужно "готовить".
В вашем случае я бы не брал шейпы, а напрямую загонял в базу из pbf через osm2pgsql. А дальше вы имеете геометрию дома и адрес: улица+дом; а привязку вы получаете геометрической вложенностью в полигон населённого пункта, поселения, области и т.д. Но надо быть готовым, что в деревнях в подавляющем большинстве адресации нет.