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

          Activity

          Hide
          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
          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
          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
          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
          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
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: