GML versus JSON when providing Geographical Data, speed and size factors
So here is the situation: I need to process some spatial information which I retrieve from different servers using the OGC standard WFS protocol. I simply use the GeoTools to query and process the information.
Information providers are all partners using either GeoServer or UMN Mapserver. All providers have a relative good internet connection in terms of speed but try as much as possible to spare some bandwidth (In Europe, a lot of internet connections are still volume based).
If I tell you that some spatial information stored in GML format requires more space than when stored in JSON format, you certainly will not be surprised. But about how much extra space are we exactly talking?
Since the GeoServer supports both delivery in GML and JSON format, I decided to give a quick shot to get a better idea about speed and size differences between GML and JSON.
The spatial information I used is stored in Oracle 10g and accessible through a GeoServer in a Gigabit Network.
Here are the queries I used:
Here the results:
Delivery time:
Of course, there are many other aspects besides speed and size which should be taken into consideration like for example validation issues.
Nevertheless, JSON spares a lot of bandwidth and for slower internet connections, this means sparing a lot of time when providing information.
Information providers are all partners using either GeoServer or UMN Mapserver. All providers have a relative good internet connection in terms of speed but try as much as possible to spare some bandwidth (In Europe, a lot of internet connections are still volume based).
If I tell you that some spatial information stored in GML format requires more space than when stored in JSON format, you certainly will not be surprised. But about how much extra space are we exactly talking?
Since the GeoServer supports both delivery in GML and JSON format, I decided to give a quick shot to get a better idea about speed and size differences between GML and JSON.
The spatial information I used is stored in Oracle 10g and accessible through a GeoServer in a Gigabit Network.
Here are the queries I used:
- for GML: wfs?SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&TYPENAME=topp:ACKERFLAECHEN_RLP_GK3
- for JSON: wfs?request=GetFeature&typename=topp:ACKERFLAECHEN_RLP_GK3&outputformat=json
Here the results:
Delivery time:
- WFS: 12,33s
- JSON: 8,86s
- WFS: 235 MB
- JSON: 157 MB
Of course, there are many other aspects besides speed and size which should be taken into consideration like for example validation issues.
Nevertheless, JSON spares a lot of bandwidth and for slower internet connections, this means sparing a lot of time when providing information.
ctuot - 3. Aug, 10:56
Christopher James Tuot
Compression
one easy way to reduce the network transfer size is to enable gzip compression at the http level. This is usually done at the http server/web container level.
For example, with Tomcat you have to hack the server.xml file and include the MIME types in the compressableMimeType attribute, more information here: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
This may reduce the amount of data that is actually travelling over the network by 10 times, without the user noticing it (gzip compression is part of the HTTP standard, compatible clients will handle it transparently).
CGI Application Plugin?
Thx for the tip. This is a nice and easy solution for the GeoServer which runs in Tomcat. I have tried to find a similar solution for the UMN Mapserv (cgi application) and I found this CGI Application Plugin:
http://search.cpan.org/~rhesa/CGI-Application-Plugin-CompressGzip-1.00/lib/CGI/Application/Plugin/CompressGzip.pm
At the moment, I do not have the time to test the UMN Mapserver with the CGI GZIP Plugin but if it works this could be great!