GeoServer

Allow renaming of featureTypes

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: 1.6.5, 1.7.0-beta1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

A long requested feature has been to be able to rename featureTypes, as datastores like ArcSDE can have long kind of nasty names, and often people just want something more friendly than what's in their database. Right now we make people use a view.

There is now code to rename features, used in the WFS datastore, that can actually accomplish this. We should make use of it. A UI configuration would obviously be ideal, but is a bit ambitious with our current stuff. Instead we can just make this an option for power users, by making it a configuration option only in info.xml. Call it something like displayName or outputName

Issue Links

duplicates

Improvement - An improvement or enhancement to an existing feature or task. GEOS-779 Support feature type aliases

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brent Owens added a comment -

This is a great idea. Especially for KML when the feature type names are long and obscure, they start to look crazy in google earth.

Show
Brent Owens added a comment - This is a great idea. Especially for KML when the feature type names are long and obscure, they start to look crazy in google earth.
Hide
Permalink
Chris Holmes added a comment -

Yeah, this has been a long requested feature, and indeed has had a few patches, but they only worked against WMS. We should find those issues and link them to this one.

Show
Chris Holmes added a comment - Yeah, this has been a long requested feature, and indeed has had a few patches, but they only worked against WMS. We should find those issues and link them to this one.
Hide
Permalink
Rob Atkinson added a comment -

This is just a trivial case of the community-schema support, all we would need to do would be to allow a internal feature model to be propagated from the wrapped data store.
And you would get the ability to rename any attributes, or put them into externally defined namespaces (eg gml:name) for free.
Adding configuration options will increase the hurdle for backwards compatibility.

Show
Rob Atkinson added a comment - This is just a trivial case of the community-schema support, all we would need to do would be to allow a internal feature model to be propagated from the wrapped data store. And you would get the ability to rename any attributes, or put them into externally defined namespaces (eg gml:name) for free. Adding configuration options will increase the hurdle for backwards compatibility.
Hide
Permalink
Gabriel Roldan added a comment -

Indeed using community-schema datastore would give all those benefits out of the box.
Yet, the drawback being it can't handle transactions.

I'd suggest, for the time being, if FT aliasing is a short term need, to use a very simple wrapper, yet isolating the functionality enough to easy the transition to community-schema datastore whenever we're able to
a) have a ui for it. Even if its not for the full community-schema capabilities but just for aliasing attribute names
b) unroll transactions over the community-schema ds to the underlying one(s). (Someday I'd like to get this out of the box by the use of hibernate-spatial or similar)

Show
Gabriel Roldan added a comment - Indeed using community-schema datastore would give all those benefits out of the box. Yet, the drawback being it can't handle transactions. I'd suggest, for the time being, if FT aliasing is a short term need, to use a very simple wrapper, yet isolating the functionality enough to easy the transition to community-schema datastore whenever we're able to a) have a ui for it. Even if its not for the full community-schema capabilities but just for aliasing attribute names b) unroll transactions over the community-schema ds to the underlying one(s). (Someday I'd like to get this out of the box by the use of hibernate-spatial or similar)
Hide
Permalink
Andrea Aime added a comment -

Marking as duplicate since GEOS-779 was already there. We'll add an "alias" option in the feature type configuration

Show
Andrea Aime added a comment - Marking as duplicate since GEOS-779 was already there. We'll add an "alias" option in the feature type configuration

People

  • Assignee:
    Andrea Aime
    Reporter:
    Chris Holmes
Vote (2)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: