SQL database for coords index

NINAnor / istSOS-support

Tools for importing data from sensor directly on the istSOS server.

GNU General Public License v3.0

2 stars 0 forks source link

SQL database for coords index #7

Open pesekon2 opened 7 years ago

pesekon2 commented 7 years ago

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

ninsbl commented 7 years ago

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 commented 7 years ago

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

ninsbl commented 7 years ago

See:

http://www.topografix.com/gpx.asp

and: http://web.nina.no/giswiki/doku.php?id=tasks:qgis_gpx

BTW: there are some expanations regarding CRS use in Norway here: http://web.nina.no/giswiki/doku.php?id=gisbasics:coordinatesystems

pesekon2 commented 7 years ago

Thank you. I will take a look.

pesekon2 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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...