On Fri, Apr 25, 2014 at 3:18 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Fri, Apr 25, 2014 at 11:33 AM, Sampo Savolainen <
> sampo.savolai...@spatineo.com> wrote:
>
>> Hi,
>>
>> The XStreamPersister Andrea designed is working great for me after I made
>> the small change I mentioned a few hours ago. But this still leaves part of
>> the problem of feeding featuretype.xml configuration to DataStores /
>> FeatureSources.
>>
>
> Good to hear. Btw, the XStreamPersister is Justin's work, I just did the
> initializers plugins :-)
>
>
>>
>> The parsed metadata is part of the GS catalog FeatureTypeInfo and
>> currently, I'm not aware of any mechanism to pass the metadata to the
>> actual GT feature source.
>>
>>
>
>
>> Here's a few approches I've thought of so far:
>>
>> 1. add a MetadataAware interface into GT:
>>
>> public interface MetadataAware {
>> public void setMetadata(Map<String, ?> metadata);
>> pblic Map<String, ?> getMetadata();
>> }
>>
>> The setter would be called for FeatureSources which implement this
>> interface when the FeatureSource is created, in
>> FeatureTypeInfoImpl.getFeatureSource(). This is however clumsy as the
>> FeatureSources are more often than not wrapped in other FeatureSources. And
>> as there is no common abstract class, it's a lot of work implementing this
>> for every wrapping FeatureSource, not to mention error-prone when new
>> wrappers are written.
>>
>
> Yes, that's a common issue as we wrap feature sources a lot.
>
>
>>
>> 2. Add similar methods to SimpleFeatureSource. Most classes implement
>> this anyway, so it would negate the issue of forgetting to implement an
>> extra interface for FeatureSource implementations and wrappers.
>>
>
> Hmm... still fragile, not all wrappers might be aware of it, and it's
> limited to simple features (like it or not, complex features are going to
> grow).
>
>
>>
>> 3. Add the featuretype metadata in the GT FeatureType.userData. This is a
>> crufty as this information is not really to do with the feature type, but
>> the current layer based on this feature type. There's a strong possibility
>> of things getting mixed up in situations where multiple layers are created
>> from the same feature type.
>>
>
> Except you need a feature type to start with.
>
>
>>
>> Thoughts? Any better ideas that come to mind?
>>
>
> I would generalize and externalize what we are currently doing for
> JDBCDataStores in ResourcePool:
>
>
> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L872
>
> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L844
>
> https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/catalog/ResourcePool.java#L1112
>
> That is, create a FeatureTypeInitializer interface that we can use to
> delegate all types of special initializations, the
> interface woudl act as a broker between the programmatic interfaces
> provided by GeoTools and the configuration
> stored in the feature type metadata maps
>
>
Generalizing this is definitely one way to go. I'm a bit wary of starting
doing that, especially since from the looks of it, the SQL view
implementation looks a bit iffy. See the third line you quoted:
if(dataStore instanceof JDBCDataStore && info.getMetadata() != null &&
info.getMetadata().containsKey(FeatureTypeInfo.JDBC_VIRTUAL_TABLE)) {
...
The dataStore object might already be wrapped! This means this code does
not work in every case.
What do you think about my later suggestion that we could add the metadata
as a Query hint? I'm now prototyping it so that GeoServerFeatureSource is
given the metadata map, which it then injects into Queries in
getFeatures(). It looks promising from my point of view.
Sampo
> Cheers
> Andrea
>
> --
> ==
> Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
> for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
Sampo Savolainen
R&D Director, Spatineo Oy
sampo.savolai...@spatineo.com
+358-407555649
Linnankoskenkatu 16 A 17, 00250 Helsinki, Finland
www.spatineo.com, twitter.com/#!/spatineo
www.linkedin.com/company/spatineo-inc
This message may contain privileged and/or confidential information. If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate, or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.
------------------------------------------------------------------------------
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
