beduin01

await можно использовать только в async фцнкции

Потому что в ES6 добавили краткую форму записи для методов - https://developer.mozilla.org/en-US/docs/Web/JavaS...

https://jsfiddle.net/rmjd8zp4/

v-bind:value="img" надо в input перенести

СВОЙСТВА!!! flex-basis flex-grow и flex-shrink
flex-basis - это та ширина, будем называть так, которая неотъемлима у элемента. Не хотите ее юзать - используйте min-width.
flex-grow - это "жадность" того или иного элемента. Т.е. сколько свободного пространства он съест, по сравнению с соседом (Спека: Определяет, сколько пространства может занимать флекс внутри контейнера. По дефолту = 0). Вспоминаем ФБоксовский способ прижатия футера к низу:
.wrapper {
display: flex;
flex-direction: column;
height: 100%;
}
.content {
flex: 1 0 auto;
}
.footer {
flex: 0 0 auto;
}

и flex-shrink - это то, как будут сжиматься элементы, если места хватать не будет. Антагонист flex-grow. По дефолту = 1, в отличие от flex-grow = 1 (Это ТОЛСТЫЙ намек)
Спека: Устанавливает коэффициент сжатия флексов в контейнере и задаёт, насколько элемент будет уменьшаться по отношению к другим флексам, чтобы разместить все элементы в одну строку

Базис задавать НАДО! если желаете адаптивности, при заданном flex-wrap: wrap;
Спека: Свойство flex-basis определяет основу флекса, которая является начальным размером элемента.
ВОПРОСЫ?!
https://webref.ru/css/flex-basis
https://webref.ru/css/flex-grow
https://webref.ru/css/flex-shrink

Нужны ответы? Берете простеньки макетик, а-ля Бутстрап и верстаете весь!!! на флексах. После 5-й верстки наступит Дзен! ИМХО!

У .Myheader ширина указана 100% и так же есть border 1px.
Border прибавляется к общeй ширине блока и у тебя ширина выходит 100% + 2px
Допиши box-sizing: border-box;

JSON.strinfigy сериализует JavaScript-объект в строку. Например для передачи куда-то.
geoJSON(x) в свою очередь хочет в качестве аргумента получить как раз JavaScript-объект, а не его строковое представление, которое вы ему подсовываете.
Поэтому первый вариант у вас работает, потому что y это не JSON-объект, это JavaScript Object. JSON-объектом он станет только тогда, когда вы его сериализуете через JSON.stringify
Поэтому первый вариант у вас работает - вы скармливаете JS-объект.
А второй не работает - вы зачем-то JS-объект превращаете в строку и скармливаете уже строку, хотя надо сам этот geojson

В принципе можно. Вот так, например:

var get_myvar;
var set_myvar;
window.map.on('draw:created', function (e) {
    var type = e.layerType,
        layer = e.layer;

    if (type === 'marker') {
        // Do marker specific actions
    }

     var myvar = "foo"; // вот переменная
     get_myvar = function(){
         return myvar;
     }
     set_myvar = function(val){
         myvar = val;
     }
});
console.log( "myvar="+ get_myvar() );
set_myvar("new_value");
console.log( "myvar="+ get_myvar() );

Statement - это выражение. Это нейтральный термин, а request подразумевает наличие response, не для всех sql-выражений это актуально.

Конструкция for ... in предназначена для обхода объектов, а не массивов. Для объектов можно использовать forEach.

rasters_previews_list.forEach(function(item) { 
    console.log(item.name);
});

Влияние фрагментации памяти на производительность хорошо выражено в тех системах, где существуют значительные задержки доступа к памяти прежде, чем выполнять чтение и запись. Поэтому для жёстких дисков и существует служба дефрагментации. А для памяти типа ОЗУ это делать ненужно и вредно. Потому что процессору придётся снова сбрасывать свой кэш преобразования адресов. А это уйдёт куда больше времени. Потому что с точки зрения преобразования адресов фрагментации памяти нет. То есть каждая задача видит память не замусоренной и линейной. Да и страничная организация памяти позволяет программистам жить лучше. Другое дело - сегментная организация памяти. Но они давно не используются. Сборщики мусора занимаются несколько другими задачами. Их задача - очистить память от неиспользуемых объектов в течение такого-то времени, чтобы потом не возникла проблема доступностью памяти для различных операций. Иначе произойдёт утечка памяти. Но они не занимаются дефрагментацией.

может mymap.js опустить ниже чем leaflet.draw.js ?

и еще вариант убрать leaflet.draw-src.js, т.к. leaflet.draw.js достаточно

Что конкретно значит "помог бы"? Однозначного хака, который сам собой все решит, скорее всего нет. Самый грязный хак, какой можно навскидку придумать - в БД добавить constraint на уникальность комбинации всех вставляемых полей, типа:

CREATE TABLE example (
    a integer,
    b integer,
    c integer,
    UNIQUE (a, c)
);

Подробности: Раз - Два.

Это исключит на уровне БД саму возможность повторной вставки, однако, сильно просадит перформанс вставок вообще (и, заодно, может полoмать другие кривые места, если такие есть). "Поможет" ли это - вопрос неоднозначный, т.к., если проблема действительно в повторной вставке, в коде наверняка где-то (скорее всего, в недрах NpgsqlCommand), всплывет Exception (constraint violation). Возможно, это поможет найти кривое место :) Заодно это поможет выяснить, нет ли в БД уже дубликатов, т.к. если они есть, добавить constraint просто не удастся до тех пор, пока их не вычистить.

А кроме того, "в БД оказывается два экземпляра данных" cамо по себе требует уточнения. Если Вы смотрите в БД какой-нибудь независимой тулзой, то это одно, а если с помощю самого "кривого проекта", то проблема запросто может быть на самом деле не в БД, a в запросе, которым он выбирает данные из БД, или вообще в архитектуре (когда второй экземпляр появляется не из БД, а из какого-нибудь внутреннего списка, куда он тупо вставляется). В таком случае добавление constraint ничего не даст, но, опять же, этим и поможет локализовать проблему.

UPD: В любом случае, самое правильное - с помощью этого (или подобного) хака найти проблему, после чего хак убрать! :)

UPD2: Судя по тому, как передаются значения полей для вставки (в конструктор), этот "проект" - Эльдорадо для любителей SQL Injection. Так что, не удивляйтесь, когда в один не самый прекрасный день хакеры пришлют вам поздравительную открытку :)