Geocode activity candidate is not the same in Web and Mobile
I have a workflow that uses the Geocode activity, and want to run it both the Web viewer and the Mobile app. However, when I inspect the returned candidate object, there are some differences which makes it harder to write a generic workflow.
Differences are:
- In Mobile, attributes have capitals
- The extent property is missing in Mobile, even though it is in the result of the web request
I 'fixed' the workflow by checking if the extent is set, and if not, manually create an extent based on the Location with a certain buffer. This is not an ideal situation.
Is this an oversight in Mobile, or can I do something to handle this scenario properly?
Mobile:
{
"candidate": {
"Attributes": {
"perceel": "BIL01 A 1001",
"score": 100.0,
"status": "M"
},
"Score": 100.0,
"Location": {
"x": 579292.8127107782,
"y": 6826290.290310468,
"spatialReference": {
"wkid": 102100,
"latestWkid": 3857
}
},
"Address": "BIL01 A 1001"
}
}Web
{
"candidate": {
"address": "BIL01 A 1001",
"location": {
"x": 579292.8127107782,
"y": 6826290.290310468
},
"score": 100,
"attributes": {
"status": "M",
"score": 100,
"perceel": "BIL01 A 1001"
},
"extent": {
"xmin": 579180.5761538278,
"ymin": 6826108.3293042569,
"xmax": 579405.0392564933,
"ymax": 6826472.255365216
}
}
}
-
Hi Berend,
Thanks for bringing this to our attention. Consistency between our applications is something we strive towards as we really want workflows to be as re-usable as possible. I have logged this as an issue and will try to get it investigated soon.
I think your current workaround might be the best for now.
0 -
Hi Berend,
I've done a bit more investigating and can give some more details about this.
Firstly, the upper-case characters will not be a problem if you reference the object in an expression. You should use the camel-case version as hinted by the suggestions in the expression editor. At runtime, the .NET version of workflow should correctly redirect those property references to the pascal-case equivalent.
The absence of the extent is a symptom of something else in Mobile, that we are planning to fix more comprehensively rather than having a targeted fix an individual situation like this. Essentially, the Mobile version wraps certain objects and only exposes certain properties. In this case, the extent property is not exposed from the wrapper, so you can't see or use it.
The extent property is also absent from the suggestions in the designer, because it is not included in the 3.x API version of AddressCandidate.
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
2 kommentarer