geowolf wrote: > > On Mon, Nov 7, 2011 at 3:47 PM, robpd <[email protected]> wrote: >>> Thanks for your reply Andrea. So I think that you're saying that we >>> could >>> send geographical updates (new and modified points) to the server >>> clusters >>> using something like JMS whereupon each server would publish the updates >>> to the GeoServer plugins (using WFS). Right? And each server could use >>> a >>> memory-based store like, for example, PostGIS with memory tables? > >>>> Sort of, I was really suggesting you could the points into some memory >>>> data structure (a spatial index of some sort, or a distributed memory >>>> cache like >>>> memcached) and have it updated via JMS or other messaging solution >>>> (there are many around, >>>> I was just citing a common one).A "data store" in GeoServer is just a >>>> set of classes that abstracts >>> away how you access data, there are >>>> implementations for many persistent storages >>>> like postgis, but you could roll your own if it's critical to >>>> performance. PostGIS might do as well, don't >>> know, it really boils >>>> down to your performance requirements, previous experiences with this >>>> kind of >>> problem often require near-real time updates and top >>>> performance out of map rendering and WFS, >>> that's why I was >>>> considering the in memory option (the people I've seen doing this >>>> created a store >>> that is a front-end, a bridge, to their own custom >>>> data management solution). > > OK understand thanks. So could even use something like an SRTree from JAI > (though I'm not sure it's valid for point data) > >>> I looked at the link. Seems like a way of embedding functions (that map >>> collections to collections) into SLD so that the processed results can >>> be >>> rendered in a specific way. Right? > >>>> Correct > >> Though this paradigm would work in >>> theory for any such processes, it seems to me that, given that this is >>> used to render tiles, the processes must inherently be fast-performers. > >>>> Correct again. > >>> So I think perhaps it could be used with some of the most rapid cluster >>> algorithms to produce point-clouds. One thing it could definitely be >>> used >>> for would be to appropriate newly added points into existing clusters. >>> The cluster polygons would already exist, so it should be fast to >>> appropriate the new points to them using these interfaces. Seems to >>> imply >>> that to use the interfaces etc for clustering would need a one-time (or >>> infrequent) 'start-up' clustering job followed by frequent updates of >>> any >>> new points to the existing clusters. > >>>> Yes, that is an option. >>>> Another option is to have your clustering work at the storage level >>>> (and find >>>> some way at the SLD level to summon the right clustering for the >>>> current >>>> zoom level, like using scale dependent rules). > > Interesting. Actually I already have the clusters at the storage level, > so this could be an option for me. I was previously thinking that I would > make separate layers for each zoom level - each layer consisting of the > clusters for this level. But this is a new possibility for me. Most > clustering uses a distance (or equivalently similarity) measure (e.g. > Euclidean) and magnitude - so it ought to be easy to create a function > that maps the mean spatial resolution at each zoom level to the > appropriate bunch of clusters (with their inherent distance metric and > magnitude). > > Another interesting possibility would be to store the raw points in an > R-tree like structure (as you said above) and then use the R-tree itself > to derive and maintain the clusters. There is much literature on R-tree > based clustering. This could have the benefit of being expedient from the > storage and retrieval point of view, fast and convenient. It's a bit of > an R&D project though! > > Is your set of interfaces part of the production build, or would I need to > get my own copy of the source code and compile (with my interface > implementations)? > >>>> Cheers >>>> Andrea > > Thanks. > > Rob > -- > ------------------------------------------------------- > Ing. Andrea Aime > GeoSolutions S.A.S. > Tech lead > > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > > phone: +39 0584 962313 > fax: +39 0584 962313 > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.youtube.com/user/GeoSolutionsIT > http://www.linkedin.com/in/andreaaime > http://twitter.com/geowolf > > ------------------------------------------------------- > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Geoserver-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-users >
-- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Large-Volatile-Point-Dataset-WMS-and-WFS-tp6961594p6972983.html Sent from the GeoServer - User mailing list archive at Nabble.com. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
