How to Find Places Near a GPS Track

Create a standalone tool that finds places near a GPS track with the Geoapify Places API.

Before you start
- Ask for my preferred language and runtime, whether the tool runs as a CLI, server process, or browser tool, and the desired output format.
- Ask whether the input is already a GeoJSON LineString or MultiLineString and which place categories, buffer, page size, and page limit to use.
- Ask me to configure a Geoapify API key before live requests. For a CLI or server tool, use GEOAPIFY_API_KEY. For a browser tool, ask whether to use a restricted key or a backend proxy. Never hardcode, print, or log the key.
- If I have no implementation preference, choose the simplest suitable approach and state your assumptions.

API flow
1. Accept and validate a GeoJSON LineString or MultiLineString in [longitude, latitude] order.
2. POST to the Geoapify Places API with categories and a polyline filter containing the GeoJSON geometry and an explicit buffer in metres.
3. Return the Places FeatureCollection and clear pagination metadata based on limit and offset.

Requirements
- Keep the source track unchanged. Do not simplify it or snap it to roads.
- Accept no more than 10,000 source positions or 102,400 UTF-8 bytes of inline geometry.
- Require buffer to be greater than 0 and no more than 100,000 metres; explain that omitting it uses 1,000 metres.
- Explain that the buffer measures geographic proximity, not travel distance or time.
- Handle empty pages, invalid input, timeouts, HTTP errors, and limited 429 retries with backoff.
- Bound pagination and do not describe the results as an exhaustive inventory.
- Provide concise setup and run instructions with the completed tool.

Add a “find places near this GPS track” workflow to the existing application using the Geoapify Places API.

Inspect first
- Determine the project's language, runtime, framework, HTTP client, map library, state management, environment configuration, tests, and deployment model.
- Reuse those choices and make the smallest necessary changes.
- Check whether a Geoapify API key is configured. If it is missing, ask me to add one through the existing environment or secret-management system. For browser requests, ask whether to use a restricted key or a backend proxy. Never hardcode, print, or log the key.

Clarify only what the project cannot answer
- Whether the track is already a GeoJSON LineString or MultiLineString or needs conversion from another format.
- Which place categories and buffer range the user can select.
- Whether to return one page or support bounded pagination.

Implement
1. Validate GeoJSON track positions in [longitude, latitude] order.
2. POST the track to the Geoapify Places API with categories, filter.type set to polyline, the GeoJSON geometry, and an explicit buffer in metres.
3. Integrate the returned places into the application's existing map or result view.

Quality requirements
- Do not simplify or road-snap the source track.
- Enforce the 10,000-position, 102,400-byte, and 100,000-metre buffer limits.
- State that the buffer measures geographic proximity rather than travel distance or time.
- Preserve loading, empty, partial, stale, and error states; cancel or discard stale searches.
- Bound pagination and 429 retries, add focused tests, and report changed files and assumptions.

Create a reusable “Find places near a GPS track” map component using the Geoapify Places API.

Inspect first
- Follow the application's existing framework, component, styling, state-management, HTTP, map, accessibility, testing, and deployment conventions.
- Check whether a Geoapify API key is configured. If it is missing, ask me to configure one through the project's environment or secret-management system.
- For browser requests, ask whether to use a restricted API key or a backend proxy. Never hardcode, print, or log the key.

Clarify only unresolved choices
- Supported GeoJSON track types and place categories.
- Buffer range and default value.
- Whether the component owns the API request or receives results from its parent.

Component behavior
1. Accept a GeoJSON LineString or MultiLineString with [longitude, latitude] positions.
2. Let the user choose categories and a buffer in metres.
3. Query the Geoapify Places API with a POST polyline filter.
4. Keep the track and place results in separate map layers.
5. Show places as markers and in an accessible list.

Quality requirements
- Explain that the corridor represents geographic proximity, not travel distance or time.
- Validate the 10,000-position, 102,400-byte, and 100,000-metre buffer limits without changing the source track.
- Support loading, empty, partial, selected, stale, and error states.
- Cancel stale work, clean up map resources, bound pagination and 429 retries, and add focused interaction and data-mapping tests.

Build a complete GPS track place explorer using the Geoapify Places API.

Before you start
- For an existing project, inspect and reuse its language, framework, HTTP client, map library, styling, state, environment, tests, and deployment conventions.
- For a new project, ask for the preferred language and runtime, browser or server architecture, map technology, accepted track formats, place categories, buffer range, and pagination limit. If I have no preference, choose a simple suitable stack and state your assumptions.
- Check whether a Geoapify API key is available before live requests. If it is missing, ask me to configure one through the project's environment or secret-management system.
- For browser requests, ask whether to use a restricted API key or a backend proxy. Never hardcode, print, or log the key.

Feature flow
1. Let the user load or paste a track and convert it to a GeoJSON LineString or MultiLineString when necessary.
2. Validate [longitude, latitude] positions and show the track on a map.
3. Let the user select place categories and an explicit buffer in metres.
4. POST the track to the Geoapify Places API with a polyline filter.
5. Show nearby places as markers and in an accessible result list, with bounded pagination.

Experience and reliability
- Keep the original track and place layers separate, and never simplify or road-snap the track without explicit user action.
- Explain that results are geographically close to the track and may not be easy to reach by road.
- Enforce the 10,000-position, 102,400-byte, and 100,000-metre buffer limits.
- Handle invalid tracks, empty and partial results, stale requests, timeouts, limited 429 retries, and other API errors.
- Provide responsive accessible controls, focused tests, and a concise verification report.