Andrea - you are da man! Awesome work, and great communications too - I reckon someone could follow your little experiment and write an open-source community best-practice case study around it.
On both FeatureCollections and the renderer - I think we ought to aim for having a general solution that we can override with simple features versions as an optimisation. so, maybe we create public void featureRenderer( Feature feature ); but leave public void featureRenderer( SimpleFeature feature ); if we really really need to have different processing? likewise, it would be preferable to have ReprojectingFeatureCollection being a general FeatureCollection, and maybe invoke the current one renamed ReprojectingSimpleFeatureCollection if it worth optimising behaviour. I'll be catching up with Ben's team later this week and we'll discuss how best to follow up your excelletn work. Rob On Sun, Oct 10, 2010 at 7:05 PM, Andrea Aime <[email protected]> wrote: > Hi guys, > have a look at the two attached maps. Points... polygons... pretty dumb uh? > What the image does not show is that those images have been rendered > by GeoServer > out of a app-schema data store: you're looking at complex features. > > This is the result of a little exploration of mine on rendering > complex features: I was wondering > how hard it could be and turned out not to be too hard. At least, if > the objective is restricted to just > get something on screen, as opposed to supporting full styling, decent > performance and so on > > To get there a few patches are needed, which I've attached to a number > of separate issues. > Please review them: > http://jira.codehaus.org/browse/GEOT-3282 > http://jira.codehaus.org/browse/GEOT-3283 > http://jira.codehaus.org/browse/GEOT-3284 > http://jira.codehaus.org/browse/GEOT-3285 > http://jira.codehaus.org/browse/GEOT-3286 > > Now, there are still a few nasty issues. > > First, there are no collection wrappers to reproject, force or filter > a collection of complex features. > We'll need to roll out some, though I don't know what we're going to name > them. > e.g. ReprojectingFeatureCollection is a SimpleFeatureCollection, how > do we call the complex > features version? > > The renderer API assumes simple features in a couple of spots. > One is the label cache, which I just modified in GEOT-3286 to use > Feature. No big deal, > I would be surprised to see alternate implementations of it in the wild. > > RenderListener is a different story though... there is a truckload of > implementations of that > beast and I believe there are many implementations of it around. This > is the source of the > issue: > public void featureRenderer( SimpleFeature feature ); > > Given it's an interface I'm not sure what do do about it. Do we just > go and break it? > Do we deprecate it and create a parallel one using Feature? > Suggestions welcomed. > > And then there is Query. Query lists attributes as strings. How is > thing going to play with > complex features? Not sure. In WFS we have prefixes and mappings to namespace, > is there anything like a prefix that could be used in GeoTools land? > For the time being http://jira.codehaus.org/browse/GEOT-3285 takes > care of the case > where there aren't two attribute with the same local name, but we'll > need something > better for the future. > > Ah, before you ask "what's the plan", "what's the roadmap" on this > one, a simple answer: > there's none. This patches have been developed during the weekend and > I hope they > will make complex features people live easier, but I have no > commitment on pushing this > forward in my spare time. Understood? :-) > > Cheers > Andrea > > ----------------------------------------------------- > Ing. Andrea Aime > Senior Software Engineer > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584962313 > fax: +39 0584962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ----------------------------------------------------- > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
