Create example service with real life data

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

Create example service with real life data #2

Closed ninsbl closed 7 years ago

ninsbl commented 7 years ago

One of the challenges we have is that only very few people in NINA know what SOS is and what istSOS can offer. Therefore, it would be very helpful if we could get an example service up and running that could be used as both illustration and carrot for other colleagues... Such an example should cover:

[x] data upload
[x] necessary metadata for re-use
[x] visualisation (map)
[x] visualisation (chart)
[x] data retrieval (SOS client, download from web interface)

Would be good to get some simple basic stuff running ASAP, but is a more long term endeavor (documentation for users).

ninsbl commented 7 years ago

I am writing a client example for R, which can be a good test case (i get some errors with the templogger service). Will add / share that as soon as i find the time...

pesekon2 commented 7 years ago

Wonderful! Thank you. As the server is feeded with some data, it's the right time to get this enhancement solved.

pesekon2 commented 7 years ago

I was thinking about folder demo in the repository with modificated sample data and on the Example wiki page, there will be an example on how to set up and feed the server using istSOS demo localhost.

What do you think about this? Maybe we can create a new service on ninistsos01 instead of demo localhost?

ninsbl commented 7 years ago

Yes, a an istsos demo on ninistsos01 would be a great addition to the manual.

pesekon2 commented 7 years ago

OK, I'm going to do it.

ninsbl commented 7 years ago

Given linitations in the istSOS web UI we could also raise priority for also adding VistSOS to the examples, so users and developers can easily see what they can get out...

ninsbl commented 7 years ago

The "necessary metadata for re-use" should receive a bit more attention, but that is also something I have to look at. Mainly two types of information is required:

Information about sensor placement and application purpose (e.g. ar loggers randomly placed or in a grid or along a transect ...) are they located on the surface above or below, ...
Information about how to credit the data collector (Project, project leader, citation...) as well as access constraints / licenses ...

Maybe some parts could be done using keywords in SensorML but that would require good documentation....

pesekon2 commented 7 years ago

I think that the right place for these informations is in the offering description (which gives us also the opportunity to distinguish between set of randomly located and grid sensors within one project)
That could be a problem, because there is no opportunity to write a description to a service. We can use again the offering description, but there is that problem it will be just one field containing all the informations. Or we can use much more rich options in procedures (Owner, Manufacturer, Operator etc.)... There is also possibility to define Service provider, Service identification etc. but they are for whole server and not just for service (so I don't really get why do they are named like this)

pesekon2 commented 7 years ago

Sorry, my fault. It is possible. I was in different tab than I thought.

So should I write something about this into documentation or you will maintain it (as you know more about what is necessary I think).

ninsbl commented 7 years ago

Even if I would say we (NINA) have to think a bit more about metadata, this can be closed for now