Skip to main content

Using the simple Set Field in Current Item action, I tried several format but so far it errors when trying to set.

Field to set:  MyGeoLocation

Value: Point (-0.226313394707461 51.4956119173686)

(as you can see hard coded just to test and then replace by variables)

Error message display when workflow runs is:

Retrying last request. Next attempt scheduled in less than one minute. Details of last request: HTTP BadRequest to

https://......onmicrosoft.com/sites/thissite/_api/web/lists(guid'10d943d2-b96c-4058-b622-c5d81fedb791')/Items(192)

An unexpected 'PrimitiveValue' node was found when reading from the JSON reader. A 'StartObject' node was expected.

I am guessing it's the format sent as "Point (-0.226313394707461 51.4956119173686)" that the field is expecting something else, like in CSOM oGeolocationValue.Latitude =

but how to do likewise in Nintex workflow SetField ?

Any suggestion is welcomed.

Try 0.22631S 51.49561E

this is how the mobile app delivers it, hopefully it is the same


thanks but same thing

An unexpected 'PrimitiveValue' node was found when reading from the JSON reader. A 'StartObject' node was expected.


interesting ...

I attempted to follow the stpes in this blog SharePoint Map View for Picture Library with automatic geolocation from EXIF data - Ian's SharePoint Blog

but in a Nintex workflow : failed (same error message about PrimitiveValue) and when doing the same Set Field but in standard SPD Workflow 2010 = success !

So.. is there something fishy about setting a Location field type value in Nintex Workflow for Office 365 as opposed to the same in SPD ?

I shall email Nintex Support.


Getting there : Nintex Support helped me to find that the SPD Workflow that worked was a 2010 type, then trying the same with SPD2013 workflow .. gives the same error message.

So nothing to do with a Nintex issue.

now need to find why Set field in SPD2010 works

SPD2010.png

and not the same in SPD2013

SPD2013.png


I also contacted a TE for some more information. I will forward if I receive anything.


thanks Andrew Glasser​, I guess answer might be "Geoloc field type is now officially supported ;-)"


Sean Fiene​ and I took a look and can't seem to replicate the issue.  My thought would be it has something to do with the version of NWF or SharePoint. What versions are being used as it may be something that doesn't show up in newer builds.


Hi, you couldn't reproduce the SPD steps (before doing likewise in NWF), version is office 365 so it might be that the Set Field in office 365 is different than on-prem. 


I realize this is an older post, but in case anyone else is having the same issues we did, I'll detail how we came to our solution.

SharePoint 2013 On-Prem - Nintex Workflow 3.2.5.0

Goal

Use a Nintex workflow to populate the Location (Geolocation) field in a library where the longitude and latitude are automatically pulled from the photo.

I'm not going to into how the data is pulled from the photo, because that part was already setup for our situation and I don't know how it works. Our process also had calculated fields to give us the values for longitude and latitude.

Longitude Calculation:

=IF(RIGHT(wic_System_GPS_Longitude,1)="E",Degrees_Long+(Minutes_Long/60),(Degrees_Long+(Minutes_Long/60))*-1)

Latitude Calculation:

=IF(RIGHT(wic_System_GPS_Latitude,1)="S",-(Degrees_Lat+(Minutes_Lat/60)),Degrees_Lat+(Minutes_Lat/60))

In our specific situation, there was already a SharePoint Designer workflow for this process. We tried to recreate it verbatim into Nintex, but it didn't work. We found that the Designer workflow used the "substring from index (starting at 8)" process (detailed here on technet). We found the substring portion was no longer necessary.

So, it was as simple as grabbing the longitude and latitude directly from the calculated fields. We no longer had to worry about the "float;#" problem others had in the past.

We did have one caveat though. In trying to populate the "Point ({longitude field} {latitude field})" value directly in the Update Item Nintex action as the Value, it failed. The only way we were able to get it to work was to use the Build String action, build the exact same string value and store it into a variable. Then populate the field with the variable.


Reply