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

SQL database for coords index #7

Open
pesekon2 opened this issue Aug 11, 2017 · 7 comments
Open

SQL database for coords index #7

pesekon2 opened this issue Aug 11, 2017 · 7 comments

Comments

@pesekon2
Copy link
Contributor

It should be better to have a SQL database instead of CSV file in the metadata folder.

@ninsbl
Copy link

ninsbl commented Aug 11, 2017

Maybe, or GPX would be cool! I would assume that colleagues usually collect sensor coordinates in the field using GPS. If they can feed the resulting GPX file directly into istSOS, that is probably the most efficient solution.
Then we would just have to define what info to register (and fetch from) what GPX attribute. GPX could be modified or if necessary converted / compiled in GIS.
So, in principle, I would say that CSV, GPX, and Shape input (each with fixed definition of attributes) for the location loader script would be cool and absolutely sufficient. Don`t you think?

@pesekon2
Copy link
Contributor Author

I think so. Good idea, I have never worked With GPX, but it seems really useful and most appropriate.

@ninsbl
Copy link

ninsbl commented Aug 11, 2017

@pesekon2
Copy link
Contributor Author

Thank you. I will take a look.

@pesekon2
Copy link
Contributor Author

pesekon2 commented Aug 17, 2017

After studying GPX and after thinking about your sentence:

So, in principle, I would say that CSV, GPX, and Shape input (each with fixed definition of attributes) for the location loader script would be cool and absolutely sufficient. Don`t you think?
it seems even better to use SQL to me. To create an SQL database with coords used in NINA sensors and some import scripts from GPX, CSV and Shape.

Because:

  • it would be easier and faster for the procedures2istsos script to read it from database than from some xml files.
  • Somebody will insert the name with capital letter, somebody not. It's easier to maintain it in SQL.
  • I think that you are mostly using still the same procedures and just sometimes obtain new ones, so there is no need to make it so specific. (your database will still be there, you don't have to care about unless you are going to import new sensors)

@ninsbl
Copy link

ninsbl commented Aug 17, 2017

Isn`t procedures2istsos meant for loading new sensor locations to istSOS?

I was talking / thought about the case where sensor locations had not been registered in the system (as the first step before measurements can be added).

So, once they are loaded to istSOS they are in a SQL DB, right?

And the problem with different sensor/procedure names applies mostly to the loading of the measurements to istSOS, doesn`t it?

@pesekon2
Copy link
Contributor Author

Yes, the name problem applies to the measurements loading, sorry.

I'm still not sure if I got it right. What do you mean by system. If istSOS, yes, then sensors are loaded to the system using procedures2istsos (which uses coords index file to get their geometry). If the coords index file, then the part of import from raw GNSS data to this file is missing.

I was talking about that coords index file, about creating database instead of CSV. And to this database, new locations could be imported from GPX as well as from CSV. But as I said, this import script is missing because I thought that it is faster to do it manually. But I can create it. In case you talked about this...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants