You've got a coordinate. You've got a pile of regions on a map. You need to know: which region does this point fall in, or is it inside one at all?

That single question hides inside a lot of features:

• Geofencing: is this device or user inside the zone?
• Service / delivery areas: does this address fall in our coverage?
• Spatial lookups: which territory, district, or catchment owns this point?

They all reduce to one primitive: point in polygon. Learn it once and a whole class of "is this place inside or affected by X?" questions collapses into a single query. An example usage in real world context I have done in project is "is this address in a flood zone?" the exact same way. More on that at the end.

Let me walk through it.

Given a GeoJSON dataset:

Note: Most open spatial data ships as GeoJSON, a plain-text format for shapes. A region (a delivery area, a territory, a geofence) is just a polygon:

{
  "type": "Feature",
  "properties": { "name": "Zone A", "level": "high" },
  "geometry": {
    "type": "Polygon",
    "coordinates": 
      [
        [
          [152.97, -27.47],
          [152.98, -27.47],
          [152.98, -27.48], 
          [152.97, -27.48],
          [152.97, -27.47]
        ]
     ]
  }
}

A geometry (the shape, as [lng, lat] points) plus properties. A full dataset is a FeatureCollection of thousands of these. GeoJSON is an open standard used worldwide, so once you can read one set of regions, you can read any of them.

Ingest the dataset into PostGIS

CREATE TABLE zones (
    id    serial PRIMARY KEY,
    name  text,
    geom  geometry(MultiPolygon, 4326)
);
-- load the GeoJSON with ogr2ogr (or shp2pgsql for shapefiles)

(4326 is WGS84, the standard lat/lng system GPS and GeoJSON use.)

The query:
Given a coordinate, you can use the ST_Intersects API to test if its inside any zone:

SELECT EXISTS (
  SELECT 1 
    FROM zones
   WHERE ST_Intersects(geom, ST_SetSRID(ST_MakePoint(:lng, :lat), 4326)
  )
) AS inside_a_zone;

Want to know which zone, not just yes/no? Return it:

SELECT name 
  FROM zones
 WHERE ST_Intersects(geom, ST_SetSRID(ST_MakePoint(:lng, :lat), 4326));

And that is the whole pattern: spatial data plus one intersection test.

A few use cases I have used in reallife applications:

1. Did the device enter this zone?
2. Which district is this in?
3. Is this address flooded?
4. Can we deliver to this drop off point?

Same handful of lines every time, the formula almost never change. Point-in-polygon is most of "is this location inside or affected by X?" in geospatial software. And because GeoJSON is a global standard, it isn't region-specific: your delivery map, a US boundary set, a European zone layer, all the same approach.

Experience:
I lean on this pattern heavily at my company Property X-Ray, where most of the questions are based around address lookup runs and point-in-polygon against hundreds of overlapping overlays like flood, residential zoning, crime rate and more. The hard part is never the query, it's wrangling the data. But the primitive above is the whole foundation. Once point-in-polygon clicks, a huge category of "is this place inside something?" problems becomes one query.