feat: implement OGC API Features collections endpoint (#16)

[mikemcdougall]

Summary

• Implements OGC API Features collections endpoints
  • GET /ogc/features/collections (list all collections)
  • GET /ogc/features/collections/{collectionId} (single collection metadata)
• Integrates with existing layer catalog for DRY compliance
• Provides comprehensive test coverage for collections functionality

Technical Implementation

• Shared Infrastructure: Reuses ILayerCatalog from FeatureServer to avoid duplication
• Dynamic Metadata: Converts layer definitions to OGC-compliant collection metadata
• Collections Listing: Returns all available layers as feature collections
• Single Collection: Detailed metadata for specific collection by ID
• Spatial Extent: Generates proper spatial extents for geometry layers

OGC Compliance

✅ Collection Structure:

• Standard OGC collection metadata fields
• Proper links structure (self, data, parent)
• Spatial extent with bounding box
• CRS support declarations

✅ Error Handling:

• 404 for non-existent collections
• Proper error responses with appropriate HTTP status codes

Test Coverage

✅ Collections List Tests:

• Valid collections response structure
• Required links validation (self, parent)
• Proper base URL construction
• Collection metadata completeness

✅ Single Collection Tests:

• Valid collection metadata response
• Required links validation (self, data, parent)
• 404 handling for invalid collection IDs
• ItemType and CRS declarations

Architecture Compliance

• DRY Principle: Leverages existing layer catalog infrastructure
• Vertical Slice: Collections functionality properly grouped
• Dependency Management: Follows architectural constraints
• AOT Compatible: Proper JSON contexts and minimal APIs

Integration Notes

• Collection IDs map to layer IDs (string representation of int)
• Uses existing layer catalog ListLayersAsync() and GetLayerAsync() methods
• Spatial extents use default world bounds (TODO: calculate from actual data)
• Maintains consistency with FeatureServer layer metadata patterns

Foundation for Issue #17

This establishes the collections infrastructure needed for:

• Items endpoint (GET /ogc/features/collections/{collectionId}/items)
• Collection-specific feature queries
• Proper OGC API Features workflow

🤖 Generated with Claude Code

[github-actions]

🤖 LLM Architecture Review

⚠️ Assessment: NEEDS_ATTENTION

🏗️ Architecture Review Summary

✅ Good Patterns Found:

• Comprehensive XML documentation in OgcModels.cs and OgcFeaturesEndpoints.cs ensures clarity and maintainability (src/Honua.Server/Features/OgcFeatures/Models/OgcModels.cs:10, src/Honua.Server/Features/OgcFeatures/OgcFeaturesEndpoints.cs:10).
• Proper use of Minimal API patterns in OgcFeaturesEndpoints.cs, avoiding the legacy controller pattern and adhering to the project's architectural guidelines (src/Honua.Server/Features/OgcFeatures/OgcFeaturesEndpoints.cs:12).
• Effective use of dependency injection and abstraction in OgcFeaturesEndpoints.cs by utilizing ILayerCatalog, aligning with Clean Architecture principles (src/Honua.Server/Features/OgcFeatures/OgcFeaturesEndpoints.cs:278).

⚠️ Architecture Concerns:

• [NEEDS ATTENTION] The caching policies in Program.cs might need review to ensure they align with the performance goals, especially for geospatial data which can be large and change frequently (src/Honua.Server/Program.cs:333).
• [NEEDS ATTENTION] The test coverage in OgcFeaturesEndpointTests.cs appears comprehensive, but ensure all new endpoints and critical paths are covered as per the project's testing requirements (tests/Honua.Server.Tests/OgcFeaturesEndpointTests.cs).

💡 Recommendations:

• Consider adding more granular control or configuration options for caching in Program.cs to better manage geospatial data volatility and freshness requirements:

  options.AddPolicy("OgcCollections", policy =>
  {
      policy.Expire(TimeSpan.FromMinutes(5)); // Shorter duration for frequently updated data
      policy.Tag("ogc-metadata", "metadata");
  });

• Review and possibly increase integration test scenarios in OgcFeaturesEndpointTests.cs to cover edge cases and error handling paths, enhancing the robustness of the API (tests/Honua.Server.Tests/OgcFeaturesEndpointTests.cs).

📚 Educational Notes:

• Utilizing Minimal APIs and avoiding traditional controllers helps reduce boilerplate, improve performance, and align with modern .NET practices which are beneficial for the performance-sensitive nature of geospatial services.
• Proper caching strategies are crucial in geospatial applications to balance between data freshness and system performance. Geospatial data often involves complex queries and large datasets, making efficient caching essential for scalability and user experience.

Overall Assessment: APPROVED

CRITICAL: PR/Issue Process Compliance:

1. PR is linked to GitHub issues: Yes, linked to issues OGC Items endpoint with bbox and filter #17 and OGC Collections endpoint #16.
2. Linked issues have acceptance criteria: Yes, detailed acceptance criteria are provided.
3. Code changes address the acceptance criteria: The changes implement the endpoints and models as specified in the acceptance criteria for the linked issues.

The PR adheres to the project's architectural standards and addresses the specified acceptance criteria, marking it as approved with recommendations for minor improvements and attention points.

---

Automated architectural analysis powered by OpenAI GPT-4
This review focuses on architectural patterns and design decisions
Human review still recommended for complex changes