Map Point Laravel Package

Technical Evaluation

Architecture fit. wm/map-point is a Laravel Nova 4 field package, not application-domain code. It lives entirely in the presentation/admin layer and extends Nova's field contract to render and persist PostGIS geometry(Point, …) values. That is a narrow but genuine gap: neither Eloquent nor Nova's stock field set understands spatial column types, so teams on Postgres/PostGIS typically end up hand-rolling a custom field anyway. If the target application already runs Nova on PostGIS, the package is architecturally tidy — a drop-in, auto-discovered field with no service provider wiring, no migrations, and no runtime footprint outside the admin panel. If the application does not use Nova, this package has no relevance whatsoever.

Integration feasibility. Feasible but stack-gated. Requirements are effectively: PHP 8.0+, Laravel 9/10, Nova 4 (a paid, closed-source dependency), PostgreSQL with the PostGIS extension enabled, and a geometry/geography column typed as Point. Because Laravel's schema builder has no first-class geometry type, the column must be created via raw SQL (ST_SetSRID(ST_MakePoint(lng, lat), 4326)), which means the package is only half the integration — the migration and any read-side casting/model accessor are on you. The field handles the form/detail/index views; persistence and serialization are the integrating team's responsibility.

Technical risk. The dominant risk is provenance, not code quality. Zero stars and zero dependents indicate an internal utility published by a GIS-focused agency (Webmapp), with no community validation, no third-party security review, and a bus factor of one. Nova's closed-source nature means the field's coupling surface is opaque and can shift between Nova majors. Secondary risks are spatial-correctness risks: SRID assumptions, longitude/latitude axis order (a classic silent-corruption bug), precision loss on round-trip, and null/invalid geometry handling on save. The front-end map almost certainly pulls tiles or a JS SDK from an external provider, introducing an API-key and terms-of-service dependency into the admin panel.

Key questions. Which SRID and axis order does the field assume on read vs. write? Does it support geography as well as geometry, and non-Point types? Is the map library/tile provider configurable or self-hostable? Is there a published Laravel/PHP/Nova support matrix and a stated Nova 5 path? What is the test coverage, and is there a CI pipeline? Is there an Eloquent cast for consuming the column outside Nova, or is this field the only interface? What is the maintainer's commitment level and is a support arrangement available?

Integration Approach

Stack fit. Compatible only with Laravel + Nova 4 + PostgreSQL/PostGIS. It is inert on MySQL, MariaDB, or SQLite — a hard non-starter for most Laravel estates and the single largest filter on applicability. Within a matching stack, the blast radius is small: the package touches one admin resource and one column type, so a failed pilot costs a branch, not an architecture.

Migration path. Add the geometry column alongside existing latitude/longitude numeric columns rather than replacing them, backfill with a single UPDATE … SET geom = ST_SetSRID(ST_MakePoint(lng, lat), 4326), and dual-write until the field has been validated. Add a GiST index on the new column at the same time — it is cheap at low volume and painful to add later under load. Keep the legacy columns until every consumer (reports, exports, APIs) reads from the new column.

Compatibility. Pin Nova to a specific minor and treat a Nova major upgrade as a formal migration project, not a routine composer update. Verify the PHP and Laravel constraints in composer.json against the host application before adoption, and check for transitive constraint collisions — the package's own dependency footprint may be minimal, but Nova itself constrains Laravel versions.

Sequencing. (1) Timeboxed spike in a throwaway branch on a scratch database, one known landmark coordinate, verifying the round-trip in raw SQL. (2) Confirm SRID and axis convention are documented and asserted in a test. (3) Add column, backfill, index, dual-write. (4) Enable the field on one Nova resource and one power user. (5) Cut over reads. (6) Decide vendor-risk posture — vendor the source into the repo or wrap it behind an internal field class — before it reaches more than one resource.

Operational Impact

Maintenance. Expect to own this. Zero dependents means no downstream bug reports, no published issue history to mine, and no pressure on the maintainer to keep pace with Nova or PHP releases. Budget a small annual allowance for patching on PHP/Laravel/Nova upgrades, and plan to fork or vendor the source at adoption time so a repository deletion or abandonment is a non-event.

Support. There is no SLA, no support contract in evidence, and documentation depth is unknown. Internal ownership — a named engineer who understands the field and the SRID convention — is a prerequisite, not a nice-to-have.

Scaling. Operationally negligible. This is an admin form field; it adds a few hundred kilobytes of JS to the Nova bundle and one map render per page view. The scaling conversations that matter are PostGIS ones — GiST indexes, bounding-box query patterns, ST_DWithin vs. ST_Distance — and are entirely independent of this package. The one scaling caveat is tile-provider rate limits if many admins use the map concurrently.

Failure modes. (a) Map provider outage or expired API key — field becomes unusable but data is intact; degrade gracefully to raw coordinate inputs. (b) SRID or axis-order mismatch — the worst case, because it corrupts data silently and is discovered downstream in analytics or routing. (c) Nova major upgrade — field breaks, admin panel loses spatial editing until patched. (d) Composer constraint conflict on upgrade — blocks unrelated dependency work. (e) Invalid or null geometry submitted — surfaces as a raw database error rather than a validation message. Each of these wants an explicit mitigation: a fallback input mode, a validation rule, a pinned Nova version, and a round-trip test asserting a known coordinate.

Ramp-up. Shallow for anyone who has built a Nova field; the package's surface is one or two classes and a Vue component. The real learning curve is GIS literacy — SRID, axis order, geometry vs. geography, coordinate precision — which the team needs regardless of whether it adopts this package. Write the convention down in the repo README and in a test; the next engineer will not infer it from the code.