DataStore getView opperation

Description

DataStore really needs a getView entry point, Currently GeoServer has the code. We simply need to point this over.

GetView opperates allows the limitation of a DataStore to being based on a single Query object.

Since Query is fairly high level this provides the API with:

  • specifcation of attribute order (required for WFS)
    * limitation of results by a Filter
    * assigning a coordinate system
    * reprojection (even from an assigned coordinate system)

GeoServer currently allways wraps its getFeatureSource( typeName ) calls with a wrapper performing the capabilites described above.

The task is to move this code over to geotools2

Environment

None

Activity

Show:
codehaus
April 10, 2015, 3:06 PM

CodeHaus Comment From: groldan - Time: Fri, 23 Apr 2004 17:56:04 -0500
---------------------
As for adding Query to MalLayer most of the code needed to resolve this issue has been ported to DataUtilities, it could be a good time to have GeoServerFeatureSource, DataStore.getView and LiteRenderer all using the same utility (DataUtilities.mixQuery(Query, Query)).

So the question is if there exists enough acceptance for adding getView to the DataStore interface.

codehaus
April 10, 2015, 3:06 PM

CodeHaus Comment From: jgarnett - Time: Fri, 4 Jun 2004 03:01:06 -0500
---------------------
Views Generated by Joins could be provided by a DataRepository.

codehaus
April 10, 2015, 3:06 PM

CodeHaus Comment From: jgarnett - Time: Mon, 31 Jan 2005 19:45:11 -0600
---------------------
Chis Holmes if you want any action on this in the 2.1 timeframe speak up soon.

codehaus
April 10, 2015, 3:06 PM

CodeHaus Comment From: jgarnett - Time: Sun, 5 Jun 2005 17:45:26 -0500
---------------------
This was resolved sometime ago, not quite as complete as the GeoServer implementation.

Assignee

Unassigned

Reporter

codehaus

Triage

None

Components

Fix versions

Affects versions

Priority

Medium
Configure