Skip to main content

CR NEPS Module

This page explains how NEPS supports Caution Report flow.

This flow checked against current code in intt-portal and mvp2-data-service.

API Endpoints​

  • GET /data/neps/get-building-id
  • POST /data/neps/import-fence-data
  • GET /data/neps/get-building-latlong
  • GET /data/neps/update-point-coordinate

Bottom line​

NEPS Module in CR flow not separate ticket engine. It acts as geospatial helper.

Main CR-side use today:

  • convert pinned lat + long into building candidates
  • support area/building selection during CR creation
  • maintain polygon and point-coordinate data used by lookup

Main CR use​

Portal CR create page calls:

  • GET /data/neps/get-building-id

Trigger points confirmed in code:

  • after user pins map location
  • when user clicks generate building ID from manual lat and long

So NEPS helps fill building-related context before CR create submitted.

Runtime flow for building lookup​

StepWhat system does
user chooses locationmap pin or manual lat/long
portal calls NEPS lookupdata/neps/get-building-id
backend validates inputboth lat and long required
backend finds matching polygonsearches area polygons covering point
backend adds sibling building candidatesloads other area data under same parent
backend returns building listeach item has buildingId, longitude, latitude
portal uses resultupdates building choices and last-layer input

What happens if lookup fails​

If no polygon matches given coordinates, backend throws exact business message:

"Given Lat/Long doesn't match to any building polygon. Please provide the building ID manually."

Portal handles this case and warns user, then allows manual building selection path.

Important meaning:

  • NEPS lookup helpful
  • not mandatory when polygon match missing

Other NEPS endpoints confirmed​

NEPS module also exposes:

  • POST /data/neps/import-fence-data
  • GET /data/neps/get-building-latlong
  • GET /data/neps/update-point-coordinate

Business meaning:

  • import-fence-data loads building boundary JSON into polygon storage
  • get-building-latlong resolves coordinate from building ID
  • update-point-coordinate recalculates point coordinate from stored polygon midpoint

These look admin or maintenance oriented, not normal CR end-user flow.

What backend returns​

Lookup response item shape confirmed:

  • buildingId
  • longitude
  • latitude

Backend builds this from AreaData.coordinate.

Important implementation nuance​

NEPS code exists in both:

  • mvp2-data-service
  • mvp3-ticket-service

But current CR portal flow shown in repo calls:

  • data/neps/get-building-id

So for current CR documentation, mvp2-data-service path is direct confirmed path.

Flowchart verdict​

NEPS Module flowchart useful, but safest code-backed reading:

  • NEPS in CR context = geospatial building resolver plus polygon maintenance
  • not separate CR status or ticket lifecycle
  • main user-facing value = helping map location become building selection

Code references​

  • intt-portal/src/app/components/pages/main-modules/cr/cr-create/cr-create.component.ts
  • mvp2-data-service/src/modules/neps/neps.controller.ts
  • mvp2-data-service/src/modules/neps/neps.service.ts
  • mvp2-data-service/src/modules/neps/neps-response.model.ts