spatial-access: Add version 1.0.2

[luhenry]

• Package: spatial-access
• Version: 1.0.2
• Source: https://github.com/GeoDaCenter/spatial_access
• Docs: https://github.com/GeoDaCenter/spatial_access

Compiles a Cython/C++ extension (_p2pExtension) for travel-time and spatial-access matrix computation. Upstream publishes no riscv64 wheel.

Mirrors upstream's build-publish.yml.

Differs from upstream

• Regenerates _p2pExtension.cpp with a current Cython before building - the released sdist's pre-generated glue predates current CPython's PyTypeObject/PyFrameObject layout and fails to compile.

Testing

• Runs only tests/test_networkUtility.py; the rest of tests/ needs the full GIS dependency chain (geopandas, fiona, osmnet, ...), and test_pyTransitMatrix.py fails identically against the real released wheel (pre-existing upstream bug, not riscv64-specific).

License: OK

Built on cp311/cp313 (x86_64 rehearsal); 2 passed.

[luhenry]

CI triage for this PR:

What failed: all four Build spatial-access 1.0.2 cp3xx-manylinux_riscv64 jobs in the single build run (38379504899) show status: completed, conclusion: cancelled, with started_at/completed_at exactly 24h apart and no runner_id/steps ever recorded. Publish spatial-access was then skipped as a result. The check_commit_messages / check_patches / check_packages_yaml lint checks all pass.

Root cause: these jobs never got scheduled onto an ubuntu-24.04-riscv runner — they sat queued until GitHub's 24h queued-job timeout auto-cancelled them. Per the actor/timing check from the skill's gotcha 48 (a human cancel is a sub-minute created_at→updated_at delta tied to a login; this one is a full 24h gap with no human action), this is an infra/queue-capacity cancellation, not a deliberate park and not a code or build-spatial-access.yml defect. The workflow itself matches the established pattern (matrix, CIBW_BEFORE_BUILD Cython regen, scoped test command) and needs no change.

I also see the shared riscv64 runner pool is currently under heavy load repo-wide (many other PRs' build jobs queued concurrently right now), so this looks like transient capacity pressure rather than anything specific to this package.

Action taken: re-ran the build (POST /actions/runs/38379504899/rerun, attempt 2) per gotcha 508's recovery path — no push, no code change. If attempt 2 also times out waiting for a riscv64 runner, that's a capacity question for a maintainer (more riscv64 runner capacity or prioritization), not something a patch to this package can fix. No patch or workflow change was made since there's no actual build/test failure to fix.