просто нужно универсальное решение

да я думаю как лучше сделать... структурой описать или как

А есть варианты? Структура В которой есть массив структур

по сути есть вариан оставить после десериализации в Json объекте

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

Поле features - это ассоциативный массив структур, в которое есть поле юиона и поле Тип

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

такого не может быть

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

Значит это невалидный geojson

http://gis-lab.info/docs/geojson_ru.html#02

второй пункт

Объект GeoJSON может иметь необязательное свойство «crs»

вот тут может быть, а может не быть

я вот сейчас задумался

а разве json вообще позволяет поля с 1 именем?

как то так будет? ` struct MyData { string type; Type t1; } struct Type { string type; string geometry; string property; }`

это должно как-то регламентироваться в стандарте json

Поле features - это ассоциативный массив структур, в которое есть поле юиона и поле Тип

Когда мы хотим получить значение - мы сначала смотрим тип А потом получаем данные из юниона Всё

по сути это сделанно в типе Json в vibe и в JSONValue в std

так что вопрос в архитектуре

как то так будет? ` struct MyData { string type; Type t1; } struct Type { string type; string geometry; string property; }`

почему geometry это строка?

А как лучше если оно: "geometry": {"type": "Point", "coordinates": [102.0, 0.5]},

а вот тут уже сложнее

Все геометрии, тип которых отличен от «Geometry Collection», должны иметь свойство «coordinates». Значение данного свойства всегда представляет собой массив. Структура элементов массива определяется типом геометрии.

и что ты в строке будешь хранить?

кусок json строки?)

да...

тогда какой смысл это всё в структуру делать?

Все геометрии, тип которых отличен от «Geometry Collection», должны иметь свойство «coordinates». Значение данного свойства всегда представляет собой массив. Структура элементов массива определяется типом геометрии.

Там есть ограниченный набор типов для Geometry

я просто боюсь с уровнем вложенности структуры запутаться

это то понятно

но это подразумевает переменный тип

либо наследование

а классы в качестве точек это плохо

вернее наоборот

точки в качестве классов

тут уже придётся tagged union делать

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

типа alias ElemT = megaTemplateStructConstructor!(Type1,Type2,Type3); ElemT a; if( a.isType1 == true )

А может проще как JSON будет оставить все же? И написать метод хождения по нему?

это твой код и твоё решение)

в принципе это минимум работы

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

ты её будешь всегда как-то подразумевать в алгоритмах

и тогда твой код будет ломаться, когда будет исполнятся алгоритм, а не когда будет парситься json

это ты про метод работы с JSON ?

самопальный

я про программу в целом

зачем тебе самопальные методы работы с json?

что vibe за тебя распарсит строку с json'ом, что std.json, всё приходит к одному

у тебя будет root объект json, а какую он имеет структуры ты узнаешь, только когда начнёшь его использовать

не, я допустим если мне нужно будет для каждого JSON поле имени получать

допустим сделать метод получения имени или типа геометрии

для каждого

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

и что такое "поле имени"?

ну { "type": "Feature", "properties": { "ID": 203, "NAME": "RUSSIAN FEDERATION",

ну так properties вообще не имеет регламентированной структуры

а ну да точно

NAME может там быть, а может и не быть

насчёт этого мы в самом начале сказали)

Вообще хранение в БД что даст то?

Какие минусы от ФС получу?

сложнее будет сделать операции вида: "получить набор документов с таким-то типом" ?

да

как раз об этом писал

как ты себе представляешь эту операция на ФС вообще?

м... жаль что для Ди ничего кроме https://gitlab.com/PiotrekDlang/DraftLib/ нет

а то как по мне то что нужно. Минимум фишек и портабельная

ERROR: S client not available

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

и что она делает?

Структуры позволяет в виде коллекция хранить

мне кажется это не что-то особенное

Для ди альтернатив нет

Просто монги и тд слишком тяжеловесны

а что за база тут используется?

а...

это и есть сама по себе база

напиши автору, спроси его платы

Objects").filer!(obj => obj.identity.name.canFind("J") && obj.age > 20);

На вид то что надо

а что надо то было?)

не, я допустим если мне нужно будет для каждого JSON поле имени получать

это?

Просто как хранилище

Dub можно поставить на Ubuntu через apt? https://github.com/dlang/dub#debianubuntu-linux

или больше неактуально?

никто не знает случайно?

а вообще на линуксе много кого тут?

у меня fedora

arch/ubuntu

на из ауры поставил без проблем

на арче*

видимо федорой в сообществе мало кто пользуется

а это важно из пакета или из тарбола?

да нет, просто хотел поставить из пакета

а все, заробило

ключик не добавил

и в итоге там d-apt)

Так, а что мне мешает sqlite заюзать и хранить геоджейсон в текстовом поле

Предварительно заполняя инфу которую про него получается выцепить

Есть минусы?