Wkb Parser Laravel Package

Product Decisions This Supports

• Incremental geospatial feature delivery. Enabling location-aware features (store locators, delivery zones, asset tracking, property listings) without adopting a full GIS platform. A WKB parser is the narrow decoding layer that turns spatial columns into usable PHP values.
• Build vs. buy for format parsing. Well-Known Binary is an OGC specification with edge cases (byte order, geometry collections, Z/M dimensions, SRID handling). Writing and maintaining a compliant decoder is non-differentiating work. An MIT-licensed parser is a defensible "buy" decision that redirects engineering capacity toward product surface.
• Data pipeline decisions. Choosing whether geometry is decoded application-side versus letting the database (PostGIS ST_AsGeoJSON, ST_AsText) or a tile/map service own it. This package supports the "decode in PHP" option when the DB is MySQL, when the API layer must remain database-agnostic, or when raw WKB arrives from third-party feeds or message queues.
• Integration scope for roadmap items. Whether a planned feature needs reading geometry only (mapping, display, export, boundary checks in application code) versus computing on geometry (buffers, unions, intersections, precise distances). This package covers the former; it does not justify a roadmap that assumes the latter.
• Vendor and dependency posture. A small, single-purpose, MIT-licensed dependency is easy to isolate behind an internal interface — a low-cost hedge that keeps a future swap to a richer geometry library from becoming a rewrite.

When to Consider This Package

Adopt when most of the following hold:

• Your persistent geometry arrives as WKB — typical sources are PostGIS columns read without transformation, MySQL GEOMETRY/POINT columns, spatial exports, or binary geometry fields in third-party APIs and event payloads.
• You need decode-only semantics in PHP: inspect a geometry, extract coordinates, hand it to a renderer or serializer, validate an inbound shape.
• You want no native extension or system dependency — no GEOS, no GDAL, no Proj bindings — so containers stay slim and deploys stay simple.
• The workload is moderate volume and latency-tolerant: request-time decoding of a handful of geometries, batch jobs, imports. Not millions of rows per request.
• You are comfortable wrapping it behind your own interface so the rest of the codebase never sees the package's types.
• You can live with a small community footprint. The WKB format is stable and spec-defined, which limits maintenance risk, but you should be prepared to fork or vendor the code if the upstream goes quiet.

Look elsewhere when:

• You need geometry operations, not just parsing — area, length, containment, intersection, buffering, snapping, accurate geodesic distance. Reach for a PostGIS/GEOS-backed approach or a fuller geometry library.
• You need a broader format surface: WKT, GeoJSON, KML, GPX, shapefiles, or conversions between them. Use a comprehensive geo library rather than stacking single-format parsers.
• You need coordinate reprojection between SRIDs. That is a projections library's job, and it is a different problem from parsing.
• Your geometry already lives in PostGIS and is consumed by a map client. Let the database emit GeoJSON or vector tiles and skip the PHP hop entirely — fewer moving parts and better performance.
• You are doing high-throughput spatial querying. Spatial predicates belong in an indexed spatial database, not in application code.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed utility that lets us read the standard binary geometry format used by our database and by external data partners. It is the cheapest possible path to shipping location-aware features: no GIS platform license, no specialized infrastructure, no new operational surface. It is deliberately narrow — it reads geometry, it does not compute on it — which keeps the commitment reversible. If we later need heavier spatial analysis, we swap the implementation behind an internal interface rather than rewriting the product.

For engineering: The package is a focused, spec-compliant WKB decoder. It removes a tedious, error-prone parsing task — byte order, geometry type dispatch, nested collections, dimensional flags — from our backlog. The integration is deliberately contained: we wrap it behind a single GeometryDecoder interface so the dependency is confined to one adapter and can be replaced by a database-side conversion or a full geometry library later. The trade-off is explicit: no geometry math, no reprojection, no alternative formats. If a requirement demands any of those, we should make that a separate, deliberate decision rather than stretching this dependency. Maintenance risk is modest — the format is frozen by specification and the code surface is small — but we should pin the version and be prepared to vendor it.