CZML streaming example

It looks like this question has been asked before but I have been unable to find a proper answer. I am familiar with PHP, but new to Javascript, and cannot figure out how to stream CZML.

I want to show about 11.000 assets on a map. To prevent the webpage from showing up AFTER everything is loaded (and testing the users' patience), I want it to show and then load the assets in the background.

Can somebody point me to an example on how to do this?
I can manage to load the czml file like this:

var czmlDataSource = new Cesium.CzmlDataSource();
viewer.dataSources.add(czmlDataSource);
czmlDataSource.loadUrl('some_file.czml');

But that's as far as I got :frowning:
I understood I should use different packets in the CZML file so my CZML file looks like this:

[
event: czml
data: {
    "id":"document",
    "version":"1.0"
  }

event: czml
data: {
    "id":"1",
    "billboard":{
      "image":"label.png",
      "verticalOrigin":"BOTTOM",
      "show":true
    },
    "position":{
      "cartographicDegrees":[
        20.0, 50.0, 0
      ]
    }
  }

event: czml
data: {
    "id":"2",
    "billboard":{
      "image":"label.png",
      "verticalOrigin":"BOTTOM",
      "show":true
    },
    "position":{
      "cartographicDegrees":[
        10.0, 52.0, 0
      ]
    }
  }
]

Help is greatly appreciated!

*bump*
Anybody? How come there is so little info on this, is this some secret code?

I've been trying all sort of new things tonight but without luck. I could post the code but since I know the code doesn't work, I would really appreciate if somebody could provide me with a working example. Thank you!

Looking at your original post.

event: czml should not be part of the json. Its a protocol thing that is used to tell that now more data is coming. I dont have a working example that I can show you. But you need to look more into the Server Side Event stuff to understand that before you try to stream czml.

Thanks for your reply Poul.
The "event:czml" actually comes right from the CZML structure Wiki on gitHub, but I understand now I misinterpreted that (source: https://github.com/AnalyticalGraphicsInc/cesium/wiki/CZML-Structure#eventsource-and-streaming)

However, I did try without it as well, without success. I also started looking into event handlers and used this website:

Especially his demo app (at the bottom of the page) was useful. I can now create a stream of data, create an event listener and get that data to the browser. But that's about it. I still don't manage to actually put it into Cesium and create a billboard.

It's such a shame that there are no working examples because demos show that it is possible.

So please, examples, tips and tricks are welcome!

I just went through the same thing a couple weeks ago.

Here is what I used on my client side to get it to stream:

//Create new CZML datasource
var czmlStream = new Cesium.CzmlDataSource();
var czmlStreamUrl = ‘http://localhost:8080/czml-stream’;

//set up EventSource
var czmlEventSource = new EventSource(czmlStreamUrl);

//Listen for EventSource data coming across as event: czml
czmlEventSource.addEventListener('czml', function(czmlUpdate) {
  //process the 'data:' coming across as JSON into the datasource
  czmlStream.process(JSON.parse(czmlUpdate.data));
}, false);

//put the datasource into Cesium
viewer.dataSources.add(czmlStream);

You may have to play around with how you are sending the data across the stream to get it to parse properly. If I remember correctly I don't believe you need brackets around it when streaming, just the individual packets.

I just switched to using sockets to send info because I needed it done in a much more controlled fashion than streaming but EventSource works well for direct streaming.

Hope that helps!

Forgot to mention, You will need to add a double return between packets, like so:

event: czml
data: {'czml data being sent}\n\n

event: czml
data: {'czml data being sent}\n\n

The double return '\n\n' lets EventSource know the packet is finished and to look for the next one.

You can have multiple lines of data like this with a single return '\n':

event: czml
data: { start of czml data\n
data: middle of czml data\n
data: end of czml data}\n\n

When dealing with large packets it's sometimes easier to break it up into chunks.

My guess is that the reason that are not many examples on this is that it require server side code also to actually send the streaming data.

Brent seems to have the answer you are looking for on the client side. I only wanted to point out that as you also figured out by now, that you misinterpreted the wiki page. I dont have the solution for you though.

Most of the answers here were related to SSE (Server Sent Events). That will certainly work, but I’ve got an example for you in websockets.

As Poul said, the reason you might not see so many examples is because it requires server side code, the same is true with websockets as well.

The first thing you can do is set up a web socket server, I’ve culled out a few lines of code from a Python script, it doesn’t matter if you know Python, you should be able to get the basis:

def emit_results(results):
    '''
    Emits the data we have in results over a websocket.
    This is an example of a single record / entity in CZML
    '''

    czml = {"id":"document","version":"1.0"},{'id': results['cttn'], 'position': {'cartographicDegrees': [results['longitude'], results['latitude'], results['altitude']]}, 'point': {'pixelSize': 3, "color": {"rgba": [0, 0, 255, 255]},'outlineWidth': 0}}

    # emit the data on a websocket event called 'czml-test' in the namespace of 'test'
    socket_io.emit('czml-test', {'data':json.dumps(czml)}, namespace='/test')

Then you just need to have some javascript on the other side that knows how to capture the websocket message. As you will see in the code below I’ve shortcut keeping count of the entities for the purpose of the example. I’ve also dealt with the czml datasource two ways. One is to only add the czml datasource a single time (after adding the first entity), then after that I simply process the data. If I were to either take out the entityCount loop or uncomment the viewer.dataSources.add(czmlDataSource); line, then I would add a new datasource for every czml “document” received. If you leave it as is, then it will uodate / move any entities you have already drawn.

<head>
    <script type="text/javascript" src="//cdnjs.cloudflare.com/ajax/libs/socket.io/0.9.16/socket.io.min.js"></script>
</head>

<body>

    ....
    ....
    <script>

        ....
        ....
        // Capture CZML based messages, using our 'czml-test' event

        socket.on('czml-test', function(msg){

            // Parse our message data
            var response = JSON.parse(msg.data);

            // If we haven't been through yet, then we need to
            // process the new data and add the datasource to the
            // viewer datasources.  But, we only want to do it once
            // for the sake of efficiency.  Every other time we want
            // to make sure we only process the new data.

            // For the sake of the example, assume we have a variable
            //called entityCount that has a count of the entities
            // in the viewer EntityCollection
            if ( entityCount == 0 )
            {
                czmlDataSource.process(response);
                viewer.dataSources.add(czmlDataSource);
            }
            else
            {

                czmlDataSource.process(response);

                // Leaving this next line will result in a new point being
                // drawn without removing the previous points.
                // Taking this line out results in clearing all previous
                // points and drawing a new point.
                // NOTE: The Cesium selector follows the most recent point.
                //viewer.dataSources.add(czmlDataSource);
            }

        });

        ....
        ....
    </script>

    ....
    ....
</body>

I hope that helps!

Hello I am also fighting with czml streaming , my current situation is that I am able to send and read data (Server = java sse, client = EventSource as in the previous post ) .
But the matter is about how to stream ?
I am using Cesium example , the czml example .
I am able to send the whole simple.czml and it work exactly as in the original example ( reading form file , without a server) .
But I need to split data as I can send a first packet/s and after send many single packet each providing a coordinate update .
Then I am sending the first 2 packets contained in czml2.json file (2 json object,the second json object contain initialization properties and the first 8 sampled coordinates) and after a sequence ( starting form 9th sample)

----czml2.json file -----------
[
{
“id”:“document”,
“name”:“simple”,
“version”:“1.0”,
“clock”:{
“interval”:“2012-03-15T10:00:00Z/2012-03-16T10:00:00Z”,
“currentTime”:“2012-03-15T10:00:00Z”,
“multiplier”:60,
“range”:“LOOP_STOP”,
“step”:“SYSTEM_CLOCK_MULTIPLIER”
}
},
{
“id”:“Satellite/ISS”,
“name”:“ISS”,
“availability”:“2012-03-15T10:00:00Z/2012-03-16T10:00:00Z”,
“description”:"\r\n

The International Space Station (ISS) is a space station, or a habitable artificial satellite in low Earth orbit. It is a modular structure whose first component was launched in 1998. Now the largest artificial body in orbit, it can often be seen at the appropriate time with the naked eye from Earth. The ISS consists of pressurised modules, external trusses, solar arrays and other components. ISS components have been launched by American Space Shuttles as well as Russian Proton and Soyuz rockets. In 1984 the ESA was invited to participate in Space Station Freedom. In 1993, after the USSR ended, the United States and Russia merged Mir-2 and Freedom together.\r\nThe ISS serves as a microgravity and space environment research laboratory in which crew members conduct experiments in biology, human biology, physics, astronomy, meteorology and other fields. The station is suited for the testing of spacecraft systems and equipment required for missions to the Moon and Mars.

\r\n\r\n

Since the arrival of Expedition 1 on 2 November 2000, the station has been continuously occupied for 13 years and 86 days, the longest continuous human presence in space. (In 2010, the station surpassed the previous record of almost 10 years (or 3,634 days) held by Mir.) The station is serviced by a variety of visiting spacecraft: Soyuz, Progress, the Automated Transfer Vehicle, the H-II Transfer Vehicle, Dragon, and Cygnus. It has been visited by astronauts and cosmonauts from 15 different nations.

\r\n\r\n

After the U.S. Space Shuttle program ended in 2011, Soyuz rockets became the only provider of transport for astronauts at the International Space Station.\r\nThe ISS programme is a joint project among five participating space agencies: NASA, Roskosmos, JAXA, ESA, and CSA. The ownership and use of the space station is established by intergovernmental treaties and agreements. The station is divided into two sections, the Russian Orbital Segment (ROS) and the United States Orbital Segment (USOS), which is shared by many nations. The ISS maintains an orbit with an altitude of between 330 km (205 mi) and 435 km (270 mi) by means of reboost manoeuvres using the engines of the Zvezda module or visiting spacecraft. It completes 15.410 orbits per day. The ISS is funded until 2024, and may operate until 2028. The Russian Federal Space Agency, Roskosmos (RKA) has proposed using the ISS to commission modules for a new space station, called OPSEK, before the remainder of the ISS is deorbited. ISS is the ninth space station to be inhabited by crews, following the Soviet and later Russian Salyut, Almaz, and Mir stations, and Skylab from the US.

",
“billboard”:{
“eyeOffset”:{
“cartesian”:[
0,0,0
]
},
“horizontalOrigin”:“CENTER”,
“image”:“data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAADJSURBVDhPnZHRDcMgEEMZjVEYpaNklIzSEfLfD4qNnXAJSFWfhO7w2Zc0Tf9QG2rXrEzSUeZLOGm47WoH95x3Hl3jEgilvDgsOQUTqsNl68ezEwn1vae6lceSEEYvvWNT/Rxc4CXQNGadho1NXoJ+9iaqc2xi2xbt23PJCDIB6TQjOC6Bho/sDy3fBQT8PrVhibU7yBFcEPaRxOoeTwbwByCOYf9VGp1BYI1BA+EeHhmfzKbBoJEQwn1yzUZtyspIQUha85MpkNIXB7GizqDEECsAAAAASUVORK5CYII=”,
“pixelOffset”:{
“cartesian2”:[
0,0
]
},
“scale”:1.5,
“show”:true,
“verticalOrigin”:“CENTER”
},
“label”:{
“fillColor”:{
“rgba”:[
255,0,255,255
]
},
“font”:“11pt Lucida Console”,
“horizontalOrigin”:“LEFT”,
“outlineColor”:{
“rgba”:[
0,0,0,255
]
},
“outlineWidth”:2,
“pixelOffset”:{
“cartesian2”:[
12,0
]
},
“show”:true,
“style”:“FILL_AND_OUTLINE”,
“text”:“ISS”,
“verticalOrigin”:“CENTER”
},
“path”:{
“show”:[
{
“interval”:“2012-03-15T10:00:00Z/2012-03-16T10:00:00Z”,
“boolean”:true
}
],
“width”:1,
“material”:{
“solidColor”:{
“color”:{
“rgba”:[
255,0,255,255
]
}
}
},
“resolution”:120,
“leadTime”:[
{
“interval”:“2012-03-15T10:00:00Z/2012-03-15T10:44:56.1031157730031Z”,
“epoch”:“2012-03-15T10:00:00Z”,
“number”:[
0,5537.546684141998,
5537.546684141998,0
]
},
{
“interval”:“2012-03-15T10:44:56.1031157730031Z/2012-03-15T12:17:13.6497999150015Z”,
“epoch”:“2012-03-15T10:44:56.1031157730031Z”,
“number”:[
0,5537.546684141998,
5537.546684141998,0
]
},
{
“interval”:“2012-03-15T12:17:13.6497999150015Z/2012-03-15T13:49:31.2088613029919Z”,
“epoch”:“2012-03-15T12:17:13.6497999150015Z”,
“number”:[
0,5537.55906138799,
5537.55906138799,0
]
},
{
“interval”:“2012-03-15T13:49:31.2088613029919Z/2012-03-15T15:21:48.776005533Z”,
“epoch”:“2012-03-15T13:49:31.2088613029919Z”,
“number”:[
0,5537.567144230008,
5537.567144230008,0
]
},
{
“interval”:“2012-03-15T15:21:48.776005533Z/2012-03-15T16:54:06.33371177400113Z”,
“epoch”:“2012-03-15T15:21:48.776005533Z”,
“number”:[
0,5537.557706241001,
5537.557706241001,0
]
},
{
“interval”:“2012-03-15T16:54:06.33371177400113Z/2012-03-15T18:26:23.8819795500021Z”,
“epoch”:“2012-03-15T16:54:06.33371177400113Z”,
“number”:[
0,5537.548267776001,
5537.548267776001,0
]
},
{
“interval”:“2012-03-15T18:26:23.8819795500021Z/2012-03-15T19:58:41.3312553199939Z”,
“epoch”:“2012-03-15T18:26:23.8819795500021Z”,
“number”:[
0,5537.449275769992,
5537.449275769992,0
]
},
{
“interval”:“2012-03-15T19:58:41.3312553199939Z/2012-03-15T21:30:58.8527762320009Z”,
“epoch”:“2012-03-15T19:58:41.3312553199939Z”,
“number”:[
0,5537.521520912007,
5537.521520912007,0
]
},
{
“interval”:“2012-03-15T21:30:58.8527762320009Z/2012-03-15T23:03:16.3758652800025Z”,
“epoch”:“2012-03-15T21:30:58.8527762320009Z”,
“number”:[
0,5537.523089048002,
5537.523089048002,0
]
},
{
“interval”:“2012-03-15T23:03:16.3758652800025Z/2012-03-16T00:35:33.8758586170152Z”,
“epoch”:“2012-03-15T23:03:16.3758652800025Z”,
“number”:[
0,5537.499993337013,
5537.499993337013,0
]
},
{
“interval”:“2012-03-16T00:35:33.8758586170152Z/2012-03-16T02:07:51.3639393709891Z”,
“epoch”:“2012-03-16T00:35:33.8758586170152Z”,
“number”:[
0,5537.488080753974,
5537.488080753974,0
]
},
{
“interval”:“2012-03-16T02:07:51.3639393709891Z/2012-03-16T03:40:08.84424079000019Z”,
“epoch”:“2012-03-16T02:07:51.3639393709891Z”,
“number”:[
0,5537.480301419011,
5537.480301419011,0
]
},
{
“interval”:“2012-03-16T03:40:08.84424079000019Z/2012-03-16T05:12:26.2685025699902Z”,
“epoch”:“2012-03-16T03:40:08.84424079000019Z”,
“number”:[
0,5537.42426177999,
5537.42426177999,0
]
},
{
“interval”:“2012-03-16T05:12:26.2685025699902Z/2012-03-16T06:44:43.7279617500026Z”,
“epoch”:“2012-03-16T05:12:26.2685025699902Z”,
“number”:[
0,5537.459459180012,
5537.459459180012,0
]
},
{
“interval”:“2012-03-16T06:44:43.7279617500026Z/2012-03-16T08:17:01.17765616998076Z”,
“epoch”:“2012-03-16T06:44:43.7279617500026Z”,
“number”:[
0,5537.449694419978,
5537.449694419978,0
]
},
{
“interval”:“2012-03-16T08:17:01.17765616998076Z/2012-03-16T08:27:42.5600708879647Z”,
“epoch”:“2012-03-16T08:17:01.17765616998076Z”,
“number”:[
0,5537.439929112035,
5537.439929112035,0
]
},
{
“interval”:“2012-03-16T08:27:42.5600708879647Z/2012-03-16T10:00:00Z”,
“epoch”:“2012-03-16T08:27:42.5600708879647Z”,
“number”:[
0,5537.439929112035,
5537.439929112035,0
]
}
],
“trailTime”:[
{
“interval”:“2012-03-15T10:00:00Z/2012-03-15T10:44:56.1031157730031Z”,
“epoch”:“2012-03-15T10:00:00Z”,
“number”:[
0,0,
5537.546684141998,5537.546684141998
]
},
{
“interval”:“2012-03-15T10:44:56.1031157730031Z/2012-03-15T12:17:13.6497999150015Z”,
“epoch”:“2012-03-15T10:44:56.1031157730031Z”,
“number”:[
0,0,
5537.546684141998,5537.546684141998
]
},
{
“interval”:“2012-03-15T12:17:13.6497999150015Z/2012-03-15T13:49:31.2088613029919Z”,
“epoch”:“2012-03-15T12:17:13.6497999150015Z”,
“number”:[
0,0,
5537.55906138799,5537.55906138799
]
},
{
“interval”:“2012-03-15T13:49:31.2088613029919Z/2012-03-15T15:21:48.776005533Z”,
“epoch”:“2012-03-15T13:49:31.2088613029919Z”,
“number”:[
0,0,
5537.567144230008,5537.567144230008
]
},
{
“interval”:“2012-03-15T15:21:48.776005533Z/2012-03-15T16:54:06.33371177400113Z”,
“epoch”:“2012-03-15T15:21:48.776005533Z”,
“number”:[
0,0,
5537.557706241001,5537.557706241001
]
},
{
“interval”:“2012-03-15T16:54:06.33371177400113Z/2012-03-15T18:26:23.8819795500021Z”,
“epoch”:“2012-03-15T16:54:06.33371177400113Z”,
“number”:[
0,0,
5537.548267776001,5537.548267776001
]
},
{
“interval”:“2012-03-15T18:26:23.8819795500021Z/2012-03-15T19:58:41.3312553199939Z”,
“epoch”:“2012-03-15T18:26:23.8819795500021Z”,
“number”:[
0,0,
5537.449275769992,5537.449275769992
]
},
{
“interval”:“2012-03-15T19:58:41.3312553199939Z/2012-03-15T21:30:58.8527762320009Z”,
“epoch”:“2012-03-15T19:58:41.3312553199939Z”,
“number”:[
0,0,
5537.521520912007,5537.521520912007
]
},
{
“interval”:“2012-03-15T21:30:58.8527762320009Z/2012-03-15T23:03:16.3758652800025Z”,
“epoch”:“2012-03-15T21:30:58.8527762320009Z”,
“number”:[
0,0,
5537.523089048002,5537.523089048002
]
},
{
“interval”:“2012-03-15T23:03:16.3758652800025Z/2012-03-16T00:35:33.8758586170152Z”,
“epoch”:“2012-03-15T23:03:16.3758652800025Z”,
“number”:[
0,0,
5537.499993337013,5537.499993337013
]
},
{
“interval”:“2012-03-16T00:35:33.8758586170152Z/2012-03-16T02:07:51.3639393709891Z”,
“epoch”:“2012-03-16T00:35:33.8758586170152Z”,
“number”:[
0,0,
5537.488080753974,5537.488080753974
]
},
{
“interval”:“2012-03-16T02:07:51.3639393709891Z/2012-03-16T03:40:08.84424079000019Z”,
“epoch”:“2012-03-16T02:07:51.3639393709891Z”,
“number”:[
0,0,
5537.480301419011,5537.480301419011
]
},
{
“interval”:“2012-03-16T03:40:08.84424079000019Z/2012-03-16T05:12:26.2685025699902Z”,
“epoch”:“2012-03-16T03:40:08.84424079000019Z”,
“number”:[
0,0,
5537.42426177999,5537.42426177999
]
},
{
“interval”:“2012-03-16T05:12:26.2685025699902Z/2012-03-16T06:44:43.7279617500026Z”,
“epoch”:“2012-03-16T05:12:26.2685025699902Z”,
“number”:[
0,0,
5537.459459180012,5537.459459180012
]
},
{
“interval”:“2012-03-16T06:44:43.7279617500026Z/2012-03-16T08:17:01.17765616998076Z”,
“epoch”:“2012-03-16T06:44:43.7279617500026Z”,
“number”:[
0,0,
5537.449694419978,5537.449694419978
]
},
{
“interval”:“2012-03-16T08:17:01.17765616998076Z/2012-03-16T08:27:42.5600708879647Z”,
“epoch”:“2012-03-16T08:17:01.17765616998076Z”,
“number”:[
0,0,
5537.439929112035,5537.439929112035
]
},
{
“interval”:“2012-03-16T08:27:42.5600708879647Z/2012-03-16T10:00:00Z”,
“epoch”:“2012-03-16T08:27:42.5600708879647Z”,
“number”:[
0,0,
5537.439929112035,5537.439929112035
]
}
]
},
“position”:{
“interpolationAlgorithm”:“LAGRANGE”,
“interpolationDegree”:5,
“referenceFrame”:“INERTIAL”,
“epoch”:“2012-03-15T10:00:00Z”,
“cartesian”:[
0,3849424.41859634,5535808.90838488,-469609.955032837,
300,2403397.25163735,5923118.10887596,-2208538.08732886,
600,681059.355577534,5629683.78882362,-3693007.85438243,
900,-1119416.00777462,4691252.20079689,-4753268.77825646,
1200,-2792163.54303408,3217045.3927905,-5269236.9636378,
1500,-4146946.26695958,1376355.11151994,-5183333.77414211,
1800,-5030073.80001301,-620907.843850796,-4506185.20959366
]
}
}
]

Ok , found the mistake : wrong id in subsequest packets !
Now I am able to stream czml correcty …

I just want to make sure I’m understanding what I’m reading here.
If I want to send a large CZML document via web sockets to the viewer I should separate the CZML document into each entity and send each one separately?

So that I end up sending a separate web socket message for each entity of the form {“id”:“document”,“version”:“1.0”},

Or is there another way to efficiently send a large CZML document to Cesium?

Regards,

Sunny Little

That’s basically correct. CZML was designed to allow for streamability. Because JavaScript is single-threaded, loading a huge block of data all at once will lock up the UI until it finishes. To avoid this, dividing data up into multiple CZML packets allows for cooperative multitasking. Each CZML packet can contain as much or as little data as you want, correlated by id.

You can have a packet with one entity, or ten entities. You can split up your sampled data across multiple packets (e.g. samples for time T through T+10 in one packet, samples for time T+10 through T+20 in the next, etc.) You can even split your graphical definitions across packets if you want (e.g. billboard data in one packet, label information in the next).

The point of all this would be to incrementally load and display important data first, while keeping the UI responsive.

As an example, our SpaceBook application loads CZML data incrementally using EventSource. Each event in the event stream contains one entity.

http://apps.agi.com/SatelliteViewer/

So, to answer your question, it all depends on how large you want your chunks to be. Smaller chunks reduce latency, larger chunks improve throughput.

Thanks,
So when I try to send the CZML in ‘chunks’ I get an error 'RuntimeError: target entity “Satellite/ISS” could not be resolved.
I’m doing the following:

Server side:

var czml = JSON.parse(fs.readFileSync(’./simple.czml’, ‘utf8’));

for(var i = 0; i < czml.length; ++i) {

var entity = czml[i];

ws.send(JSON.stringify(entity), function() { /* ignore errors */ });

}

Client-side:

ws.onmessage = function (event) {

var response = JSON.parse(event.data);

if( entityCount == 0 )

{

   czmlDataSource.process(response);

   viewer.dataSources.add(czmlDataSource);

   entityCount++;

}

else

{

   czmlDataSource.process(response);

   entityCount++;

}

};

Any suggestions?

Nevermind, figured it out, just changed the order the entities were sent over since the position of some of them referenced entities that hadn’t been processed yet.

As in my previous post I have node js server hosting Cesium and a java Server Sent Event as generator of czml stream.
I took the SandCastle Czml stream example , here I found a simple.czml file that was read directly from html page. The content of this file was :

— 1th ENTITY —
{
“id”:“document”,
“name”:“simple”,
“version”:“1.0”,
“clock”:{
“interval”:“2012-03-15T10:00:
00Z/2012-03-16T10:00:00Z”,
“currentTime”:“2012-03-15T10:00:00Z”,
“multiplier”:60,
“range”:“LOOP_STOP”,
“step”:“SYSTEM_CLOCK_MULTIPLIER”
}
},
---- 2ND ENTITY
{
“id”:“Satellite/ISS”,
“name”:“ISS”,
“availability”:“2012-03-15T10:00:00Z/2012-03-16T10:00:00Z”,
“description”:"\r\n

The Intern

… }

… other entiry (deleted in my project)

THe 2nd entity contained also a position with all dinamic data . I deleted this final part leaving just 8 sample (see previuos post) and putted all other samples in a second file that my java server read and send 1 sample per second in the form of

“data:{“id”:“document”,“name”:
“ISS”,“position”:{“interpolationAlgorithm”:“LAGRANGE”,“interpolationDegree”:5,“referenceFrame”:“INERTIAL”,“epoch”:“2012-03-15T10:00:00Z”,“cartesian”:[2100,-5341141.73000766,-2547536.97322381,-3315102.27876197]},“previousTime”:1800,“nextTime”:2400}”

I hope this is more clear … :slight_smile:

Then splitted the file content in a firs file containing an entity {id:document, version:1.0} and a 2nd entity with initial data