Page 1 of 1
xRuntime: Retrieving stored profiles
Posted: Thu Dec 09, 2021 11:45 am
by Uwe Schuster
How do I retrieve the stored profiles that includes profiles like "truck11_99t"?
The use case is profile definition in our application and retrieving profiles with the new xRoute operation getProfile (2.25). At the end the user should have the option to use built in profile XYZ or define its own profile and mainly xServer 2 internet will be used.
"Core benefits of xServer2..." does mention
https://xserver.ptvgroup.com/forum/view ... =56&t=1250
- xRuntime enables you to gather server status infos such as available stored profiles...through API
We do already use xRuntime::getDataInformation in order to show copyright information in the map. This operation is from my POV the only not deprected method that could deliver such an information like the profiles. However I do not see the profile names in the getDataInformation response and the only option in result fields is "continents" so far.
A fixed list of profile names in our application does not make sense. I could only find this list of profiles in the documentation
https://xserver2-europe-eu-test.cloud.p ... zation.htm
and there is for example the profile "electric_car" missing.
Re: xRuntime: Retrieving stored profiles
Posted: Thu Dec 09, 2021 7:23 pm
by Bernd Welter
Cheers!
Look at these two requests:
First gather a list of the available profiles with the
xRuntime2.ServerConfigurationRequest:
Code: Select all
{
"resultFields": {
"profiles": true
}
}
This will return a list of all given profiles (botrh routing and mapping, short version below):
Code: Select all
{
"$type": "ServerConfigurationResponse",
"profiles": [
{
"name": "blackmarble",
"description": "This profile contains the blackmarble rendering style.",
"useCases": [
"rendering"
],
"displayName": "Blackmarble"
},
{
"name": "4_box_truck",
"description": "A box truck with a driver delivering goods.",
"useCases": [
"routing"
],
"displayName": "Box Truck"
}
]
}
Filter the output list by the "useCases" to limit it to the routing profiles such as car, pedestarian, truck, ... I usually use this approach to create a list box with the profile names I'd like to use for the "xServe2.RequestBase.storedProfile" property.
In the next step you can request the detailed profile settings for each profile via the
xRuntime2.getConfigurationFileRequest, e.g.:
Code: Select all
{
"fileName": "profiles/routing/4_box_truck.xml"
}
to get a response such as
Code: Select all
{
"$type": "ConfigurationFileResponse",
"fileName": "profiles/routing/4_box_truck.xml",
"contents": "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\n<profile version=\"2\" dataCompatibilityVersion=\"2\" useCases=\"routing\" displayName=\"Box Truck\">\n <description>A box truck with a driver delivering goods.</description>\n <vehicleProfile>\n <engine cylinderCapacity=\"6700\" fuelConsumption=\"15.0\" emissionTechnology=\"NONE\"/>\n <weight emptyWeight=\"3905.0\" loadWeight=\"2448.0\" totalPermittedWeight=\"6353.0\"/>\n <dimensions height=\"345.0\" heightAboveFrontAxle=\"345.0\" length=\"665.0\" width=\"238.0\"/>\n <axle axleLoad=\"3775.0\" numberOfAxles=\"2\"/>\n\t\t<speeds maximumSpeed=\"115.0\">\n\t\t\t<speedRangesByNetworkClass>\n\t\t\t\t<maximumSpeeds>120.0</maximumSpeeds>\n\t\t\t\t<maximumSpeeds>112.0</maximumSpeeds>\n\t\t\t\t<maximumSpeeds>105.0</maximumSpeeds>\n\t\t\t\t<maximumSpeeds>100.0</maximumSpeeds>\n\t\t\t\t<maximumSpeeds>95.0</maximumSpeeds>\n\t\t\t\t<maximumSpeeds>50.0</maximumSpeeds>\n\t\t\t\t<maximumSpeeds>20.0</maximumSpeeds>\n\t\t\t\t<maximumSpeeds>9.0</maximumSpeeds>\n\t\t\t\t<minimumSpeeds>70.0</minimumSpeeds>\n\t\t\t\t<minimumSpeeds>38.0</minimumSpeeds>\n\t\t\t\t<minimumSpeeds>30.0</minimumSpeeds>\n\t\t\t\t<minimumSpeeds>25.0</minimumSpeeds>\n\t\t\t\t<minimumSpeeds>20.0</minimumSpeeds>\n\t\t\t\t<minimumSpeeds>10.0</minimumSpeeds>\n\t\t\t\t<minimumSpeeds>5.0</minimumSpeeds>\n\t\t\t\t<minimumSpeeds>4.0</minimumSpeeds>\n\t\t\t</speedRangesByNetworkClass>\n </speeds>\n </vehicleProfile>\n <featureLayerProfile>\n <parameters key=\"numberOfTires\" value=\"4\"/>\n </featureLayerProfile>\n <routingProfile>\n <searchSpace>\n <excludeByNetworkClass>\n <minimumDistancesFromWaypoint>UNBOUNDED</minimumDistancesFromWaypoint>\n <minimumDistancesFromWaypoint>UNBOUNDED</minimumDistancesFromWaypoint>\n <minimumDistancesFromWaypoint>UNBOUNDED</minimumDistancesFromWaypoint>\n <minimumDistancesFromWaypoint>200</minimumDistancesFromWaypoint>\n <minimumDistancesFromWaypoint>50</minimumDistancesFromWaypoint>\n <minimumDistancesFromWaypoint>20</minimumDistancesFromWaypoint>\n <minimumDistancesFromWaypoint>10</minimumDistancesFromWaypoint>\n <minimumDistancesFromWaypoint>10</minimumDistancesFromWaypoint>\n </excludeByNetworkClass>\n </searchSpace>\n <course>\n <network>\n <penaltiesByNetworkClass>\n <penalties>0</penalties>\n <penalties>10</penalties>\n <penalties>15</penalties>\n <penalties>35</penalties>\n <penalties>40</penalties>\n <penalties>90</penalties>\n <penalties>100</penalties>\n <penalties>100</penalties>\n </penaltiesByNetworkClass>\n </network>\n </course>\n </routingProfile>\n</profile>\n"
}
I guess that was the missing info, right?
Bernd
Re: xRuntime: Retrieving stored profiles
Posted: Thu Feb 24, 2022 1:31 pm
by Uwe Schuster
Thanks for the information. The getServerConfiguration request is sufficient, but this operation including a lot of other xRuntime operations is marked as deprecated. Usually this means that it should not be used for new implementations.
Can deprecated hint be ignored for getServerConfiguration and this operation is actually here to stay - or - what is the alternative operation within xServer 2?
Re: xRuntime: Retrieving stored profiles
Posted: Mon Feb 28, 2022 4:14 pm
by Bernd Welter
Hello Uwe,
Well, here's some feedback from DEV (translated by me):
The deprecated functions haven been designed to contribute within the internal dashboard.
Sooner or later we will hide these functions within the board and this simplifies the handling of "non backwards compatible changes" fopr us. [..] At this moment there's no update / dissapearance scheduled - but there's no guaranteee that these functions with these signatures remain forever.
One comment from my side: I'd miss these functions, too. For example it is quite convenient to create a list box which mentions all available profiles (rendering or routing). At least you can gather the parameters of a profile via the v2.25 method
xRoute2.getProfile().
Bernd
Re: xRuntime: Retrieving stored profiles
Posted: Thu Mar 10, 2022 2:58 pm
by Uwe Schuster
The xRoute2::getProfile method was the reason for the initial question in this thread and we are no step further, when ignoring the existance of the deprecated methods.
I am not happy with the situation that there is no non deprecated method that delivers information we need as integrators. As integrators we have no intend to replicate the dashboard and do not need any detailed piece of information the deprecated methods provide.
From my POV the devs should consider adding a new method to xRuntime that delivers the following information:
- the names of the routing and rendering profiles
(-> can currently be queried with the deprecated method ServerConfigurationRequest)
- the names of the available services
(-> right now we use the deprecated method getRuntimeInformation and check in serviceInformation if licensed and active are true for XMatch; a single true or XMatch in the list or not is sufficient, because we just want to know if we can use XMatch with that server / cluster or not w/o trying to access XMatch and receiving a HTTP 4XX error)
We need as well the information for the copyright string for the map. That is possible with getDataInformation, that is not being marked as deprecated and so there is nothing new non deprecated required.
Re: xRuntime: Retrieving stored profiles
Posted: Fri Mar 11, 2022 9:49 am
by Bernd Welter
Hello Uwe,
I just attended the sprint review and saw that there will be a new REST method in v2.26 (expected in april 2022):
- screenshot from the DEV server (11.3.2022)
This will solve the profiles topic.
About the copyright string: that was new for me. I'll forward this internally.
Bernd