Uploading 214 Land-Record Applications Before the Portal Closes
You run a Jan Seva Kendra counter that processes land-record correction applications for a block. This month 214 applications must be uploaded to the state land-records portal before the 30th. The portal accepts only PDF or JPG, with a hard limit of 2 MB per file, and one file per application. Your scanner has produced single PNG files averaging 6.8 MB each, some containing three or four pages. The tracking spreadsheet already has 214 rows, but the operator who typed it keyed names by ear, so 'Ram Lal' and 'Ramlal' both appear, and survey numbers repeat across two villages. At 4 p.m. an email arrives from '[email protected]' with the subject 'URGENT: your upload will be deleted', asking you to reply with the OTP sent to your registered mobile to 're-verify the counter'. Your supervisor is in a meeting and the portal closes at 6 p.m.
1. Describe how you will get a 6.8 MB multi-page PNG under 2 MB and accepted by the portal, and state what you must check before uploading.
Read the worked answer
Convert, do not rename. Changing the extension from .png to .pdf does not convert anything; the portal's validation will reject the file, or worse, accept a corrupt upload that later fails scrutiny.
Steps:
- Open the scan in an image/PDF tool and export as PDF with downsampling to about 150–200 dpi, grayscale rather than colour, and JPEG compression at moderate quality. A page of a scanned application typically falls well under 500 KB at these settings.
- Multi-page files: keep all pages of one application in one PDF if the total stays under 2 MB; otherwise split by page and upload as the portal's permitted parts, recording the split in the tracking sheet.
- Crop borders, remove blank pages, and straighten rotation.
Checks before upload:
- Zoom to 100% and confirm the smallest elements are readable - survey number, khata number, signatures, dates, revenue stamps. A file that passes the size test but loses the survey number is useless as evidence.
- Open the converted PDF in a different viewer to confirm it is not corrupted.
- Keep the original 6.8 MB PNG archived with a naming convention (application number + date). Compression is one-way; the original is your fallback if the portal raises a query.
- Do one test upload and check the portal's preview before batching the remaining files.
2. The spreadsheet has 214 rows with name variants and repeated survey numbers across two villages. Explain how you will identify true duplicates, including why matching on name alone fails.
Read the worked answer
Name alone fails for two reasons. First, transliteration and phonetic keying create variants of one person ('Ram Lal' / 'Ramlal', 'Mohd' / 'Mohammad') and collisions between different people who genuinely share a common name. Second, a name carries no location, so it cannot separate two different applicants in two villages.
Survey number alone also fails, because survey numbers repeat across villages; the same number in village X and village Y are different parcels.
Correct key = name + survey number + village (add khata number if recorded). Practical method:
- Add a helper column:
=COUNTIFS($B$2:$B$215,B2,$C$2:$C$215,C2,$D$2:$D$215,D2)where B is name, C survey number, D village. Any value above 1 is a candidate duplicate. - Normalise first - trim spaces, unify case, standardise spelling - otherwise COUNTIFS misses the very variants you are hunting.
- Sort and eyeball the flagged rows; do not run 'Remove Duplicates' blindly. Keep the earliest entry, mark the rest 'verify', not 'delete'.
Land-record data is disputed data: deleting the wrong row destroys an applicant's claim. Every removal must be traceable in the sheet.
3. Assess the 4 p.m. email. State the signals, the correct action, and the reasoning you would give a junior who wants to reply quickly to save the uploads.
Read the worked answer
Signals of a phishing attempt:
- False urgency with a threat - 'your upload will be deleted' with a deadline, designed to stop you checking.
- Sender domain mismatch - 'portal-verify.in' is not the official portal's domain; a helpdesk writes from the department's own domain.
- Request for an OTP - the decisive signal. An OTP is a one-time authentication secret; no genuine helpdesk, bank or portal needs it, because the system already knows the account.
- Generic salutation and no application numbers - a real notice would cite the counter ID and affected applications.
Correct action: do not reply, do not click any link, do not share the OTP. Report it to the office nodal officer/IT cell, and check the portal by typing the official URL manually rather than following the email.
Reasoning for the junior: replying cannot save the uploads. If the mail is fake, the OTP hands over the counter's login and every applicant's data; if it were real, the department would still not need the OTP. The 6 p.m. deadline is a pressure tactic, not a reason. A two-hour delay costs nothing; a leaked OTP costs the record of 214 applicants.