Support OGC API - Features #12456
Comments
|
I've created an example sandcastle to explore loading different "providers" for OGC Features APIs and visualizing them. Currently it uses the finland and ldproxy data above. This lets us easily explore the data itself but also start to get a feel for the process of managing said data with our underling I've started working on this in the Some initial thoughts and observations from this process that we should discuss:
CC @ggetz any thoughts? |
|
Bumped into an old issue with the Vineyard sample data that I opened a fix for in #12460 The bigger complication/annoyance I discovered today is that the spec does not provide a defined requirement for how to do paging other than the The only true requirements for the This will all make paging or requesting more data complicated... Probably need to discuss further |
Geospatial users are often used to dealing with the concept of layers. Given that, I think it's make sense that a "layer" in the OGC Features API vocab should map to some kind of "layer" concept in the API.
Do we want to expose a
I think we should be able to rely on this as it's required by the spec. It's probably a requirement because of use cases like this.
Is this something you're thinking of using internally for page management, or to expose via the API? Is there a need for this to live on GeoJsonDataSource at all?
I would think user's would like to load a layer and have it "just work" without having to page manually. There may be cases where a user wants to manually specify some constraints on what pages are loaded or a maximum extent, but by default I think most users would want that abstracted away. |
|
Some small updates First I added some size stats to the initial comment for all the collections from Finland and ldproxy that I've been testing. A few notable ones:
Second I threw together a first guess at the structure we should follow for implementing the necessary classes. I discussed this with @ggetz some but nothing here is final. Parts of this will probably mimic or be similar to how we handle Imagery Providers vs Imagery Layers. classDiagram
class FeatureProvider {
requestFeatures(bbox, time) Feature[]
Credit
}
class OGCFeatureProvider {
baseUrl
collectionId
maxItems
limitPerRequest
requestFeatures()
}
class FeatureLayerCollection {
FeatureLayer[] layers
moveUp/Down
add/remove(layer: FeatureLayer)
add/remove events
update(frameState)
}
class FeatureLayer {
FeatureProvider provider
Feature[] features
PrimitiveCollection primitives
EntityCollection entities : Temporary
id
name
show
update(frameState)
boundingRect
_updateBoundingRect()
add(feature: Feature)
addGeoJson(geoJson)
}
class Feature {
id
metadata
FeatureGeometry geometry
credits
toEntity() Enable easy editing?
static fromEntity()
}
class FeatureGeometry {
Rectangle rectangle
}
class EntityCollection
class Entity
FeatureProvider <|-- OGCFeatureProvider
FeatureProvider <-- FeatureLayer
FeatureLayerCollection --> FeatureLayer
FeatureLayer <-- Feature
Feature <-- FeatureGeometry
FeatureLayer <.. EntityCollection: Temp
EntityCollection <-- Entity
First version
classDiagram
class FeatureProvider {
Feature[] loadData()
}
class OGCFeatureProvider {
baseUrl
collectionId
bbox
maxItems
limitPerRequest
}
class RuntimeProvider
class Primitive
class FeatureCollection {
show
FeatureProvider provider
update()
}
class GeoJsonDataSource
class Entity
class Feature {
toEntity() Enable easy editing
static fromEntity()
}
FeatureProvider <|-- RuntimeProvider
FeatureProvider <|-- OGCFeatureProvider
Primitive <|-- FeatureCollection
FeatureProvider --> FeatureCollection
FeatureCollection --> Feature
FeatureCollection ..> GeoJsonDataSource: Temp
GeoJsonDataSource --> Entity
|
|
Thanks for the writeup @jjspace! A few clarifying comments from me on the proposed API diagram:
|
|
@ggetz Some answers to your questions. I've also updated the diagram above
|
The Spec
This issue is to track adding full support for the OGC API - Features spec as well as any discussion around the process.
The spec currently includes 5 parts with parts 4 and 5 currently under draft. The initial plan will be to support Part 1: Core with others as follow up tasks. I currently do not expect us to support Part 2 which adds CRSs which Cesium already does not do much work with.
Format/Encoding
The spec does not mandate any specific encoding or format but strongly favors HTML and GeoJSON with additional suggestions for GML. We will focus the initial implementation only around GeoJSON (especially since we already support it) with other formats being optional secondary efforts in the future as requested.
Side note: the API does not dictate a specific way to designate what format to serve. I believe most servers will implement this with the content type in headers but another suggestion from the Spec is to use a
f=[format]query parameter which I've observed utilized in other libraries and servers so my current assumption is this is one of the more generally accepted methods.Other implementations
Just listing off some other implementations I've found. Mainly from this list
ogcapi-js- lightweight and focused on the Features APIogc-client- supports multiple OGC specswindowinternallyExample data
Just an assortment of data sources from servers that we know support the OGC Features API and we can use for testing during implementation
?f=jsonto get the GeoJSON representationDataset sizes/Number of features
These are the sources + collection ids of the links listed above. As you can see we have access to quite a few different sizes of data, especially large datasets, which will be handy for testing.
The text was updated successfully, but these errors were encountered: