Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Returning specific objects as defined by official JSON files. #10

Open
jlconlin opened this issue Oct 12, 2020 · 0 comments
Open

Returning specific objects as defined by official JSON files. #10

jlconlin opened this issue Oct 12, 2020 · 0 comments
Assignees

Comments

@jlconlin
Copy link
Member

jlconlin commented Oct 12, 2020

When extracting data out of a GNDS file, we will want to have the data in natural C++ data structures (e.g., std::vector< double >, std::variant<...>, etc.). It would be good to do this in GNDStk so that each project the uses GNDStk doesn't have to do that conversion on their own.

The official GNDS documentation is based on some JSON files that contain descriptions of the contents of each of the different GNDS containers. It's possible, that these JSON files could be parsed/interpreted to automate the process so that we don't have to do a lot of work whenever GNDS changes—which it will.

Here is an example. Suppose I have a GNDStk Node representing a <values> container:

  <values>
    1.0e-05 2.04360800e+01 2.0e-05 2.04360800e+01 
  </values>

I would like to do something like this:

GNDStk::Node valuesNode = ...; // This is defined somewhere else

std::vector< double > data1 = valuesNode.values();
// or
auto data2 = valuesNode.values();

The exact API for this is to be determined, but something natural to C++.

In addition, being able to read the provided JSON files, we can support different versions of GNDS. I anticipate something like this:

#include "GNDStk/version/1_9.hpp"
// or
#include "GNDStk/version/2_0.hpp"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants