Impact of "ResponseGeometry" / "geometryOptions" (bandwidth)
Posted: Wed Sep 15, 2021 7:54 am
Cheers,
as you may know we offer to handle different geometry styles in the context of xServers:
- xServer1 : CallerContextProperty->ResponseGeometry
- xServer2 : RequestBase.geometryOptions
The style you use within a transaction may have a significant impact on the message size and therefore on the performance (depending on the available bandwidth).
Here's an example of a route (xServer2.xRoute) from Barcelona to Warszaw with a distance of more than 2300km:
So within this request I ask for the polygon line in 5 different styles. From a logical perspective the content of these 5 response elements is equal. There's no loss of quality!
Now here are the sizes of those elements:
Obviously the PLAIN style is the most bandwith consuming one. Especially for long distance routes this makes a big difference.
The benefit of the PLAIN style is that you can easily access any element of such a geometry even without the need for a specific geometry library.
The other styles may save bandwith but you may need some additional geometry frameworks to have full access to all the elements of such a geometry.
Nowadays such libraries are quite common. Even the mapping frameworks you use support them.
So if you can request geometries in WKB and then transfer them on client side in memory you may gain performance.
Best regards,
Bernd
as you may know we offer to handle different geometry styles in the context of xServers:
- xServer1 : CallerContextProperty->ResponseGeometry
- xServer2 : RequestBase.geometryOptions
The style you use within a transaction may have a significant impact on the message size and therefore on the performance (depending on the available bandwidth).
Here's an example of a route (xServer2.xRoute) from Barcelona to Warszaw with a distance of more than 2300km:
Code: Select all
{
"waypoints": [
{
"$type": "OffRoadWaypoint",
"location": {
"offRoadCoordinate": {
"x": 2.1700100683,
"y": 41.388038574
}
}
},
{
"$type": "OffRoadWaypoint",
"location": {
"offRoadCoordinate": {
"x": 21.010370204,
"y": 52.235599501
}
}
}
],
"resultFields": {
"polyline": true
},
"geometryOptions":
{
"responseGeometryTypes":["WKB","PLAIN","WKT","KML","GEOJSON"]
}
}Now here are the sizes of those elements:
| Style | Size | Relative to PLAIN |
|---|---|---|
| PLAIN | 564'324 | 100% |
| WKB | 336'429 | 60% |
| WKT | 422'382 | 75% |
| KML | 406'921 | 72% |
| geoJson | 439'520 | 78% |
The benefit of the PLAIN style is that you can easily access any element of such a geometry even without the need for a specific geometry library.
The other styles may save bandwith but you may need some additional geometry frameworks to have full access to all the elements of such a geometry.
Nowadays such libraries are quite common. Even the mapping frameworks you use support them.
So if you can request geometries in WKB and then transfer them on client side in memory you may gain performance.
Best regards,
Bernd