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