From: Andrea A. <and...@al...> - 2004-04-07 13:24:29
|
Alvaro Zabala wrote: > > Hi! Last week I sent a mail to Geotools-Devel list describing a new > project we are going to start > (AGIL: Asociación para la promoción del GIS Libre; AGIL: Association for > Impelling Open Source GIS). > > Ive been studying GeoTools2, because We think that its an strategical > projects to Java Open Source GIS Community. We think that its weakend > point is Desktop Client, so we are planning to integrate JUMP with > GeoTools. ¿Why JUMP? We think that it is a very mature solutions for the > desktop GIS, with an extensible GUI (thanks to its workbench architecture). > Althought, we dont refuse to help in another additional projects. I > visited GUI Architecture page of GeoTools, but it was a blank page, and > Jody Garnet said to me last week that they was working in a Rich Desktop > Client with Eclipse. Yep, James created that page but then did not work on it. I may filling in some content during the weekend if time permits. > After my study of GeoTools, I have some questions: > > a) Are you planning to introduce more semantic in Feature's model. I > know that OGC havent aproved an standard for RelationShips. I think to > have readed some about this, but like a proposal spec. We think that > FeatureRelationShip (1-N , M-N, Topological) would be great. We have > started some similar to GeoDatabase, with relationships between > FeatureType, and we need FeatureRelationships (here yo're validations > would play a very important role) The only thing we have now is composition, that is, a Feature attribute can be another Feature, but this is suboptimal, because we don't have ways to trigger lazy loading of the associated features at the moment. > b) Coverages. Why dont Coverage and Feature implements a commond > interface, like SpatialElement? I dont like the solutions for rendering > Coverages. Nor do I. But a Coverage and a Feature are not at the same level conceptually. A Coverage is a layer, so it's equivalent to a FeatureSource in my opinion. We don't have a common superclass because there is none in the OpenGIS spec and no-one of us still need it. > c) In JUMP-Geotools integration, I want to create a Geotools2 DAO for > JUMP (JUMP works with a "all-in-memory" model, but we have developed > some JUMP extensions to work with a DAO model). Ive thinked in > GeoTools2DAO like a wrapper of FeatureSource class. For example: > ... > this.featureSource = DataSourceRepository.getFeatureSource(new > Query("RIVERS")); > ... > public FeatureIterator getByRectangle(Envelope envelope){ > return new FeatureIterator(featureSource.getFeatures(new > BBoxFilter(envelope)).reader()); > } > Features returned by FeatureIterator will be an implementation of JUMP's > Feature and GeoTools' Feature (and they have a delagating object, the > Feature returned by GeoTools) > > Does FeatureSource work with a "not-in-memory model"? I couldnt probe > FeatureSource yet. Yes, the FeautureSource can be queried, the result of the query can be loaded a Feature at a time by using a FeatureReader. This is data streaming as opposed to full in-memory data loading. > But we dont want to save nothing in memory (or not want to save in > FeatureSource. My own DAO will have a LRU multilevel cache, with spatial > indexing capabilities) We are for sure interested in such a kind of cache. If you are integrating with Geotools could that be developed as a new set of classes in the Geotools API? > When does Filters run in memory, and when the database makes the work? Every filter that can be encoded into a query works in the database, those that cannot be encoded work in memory. > d) Where are GridCoverages data sources in last release? I couldnt find > ArcGRID James? > e) How does gridcoverage model work? We have developed a partial > implementation of OGC's GridCoverage spec, and it can load ECW images > (by wrapping a native dll of ER-Mapper) and all the formats of JAI. We > have used a DAO model too. We dont load nothing in memory (instead we > have a Tile Cache) and we work with a Tiles model (similar to JAI). Does > GeoTools model load images in memory, or it reads necessary tiles when > its necessary? A GridCoverage is a wrapper around a JAI PlanarImage, so we do have tiling and tile caching too (the ones provided by JAI). > f) Does GridCoverage model consideer Mosaic? We have image's mosaics > (all ecw files in a directory) and we use GridCoverageCollection > abstraction. To do that, we use Composite Design Pattern > (GridCoverageCollection is a collection of GridCoverage, and it extends > GridCoverage). As far as I know, not, but using JAI operators it should not be complex to create a GridCoverage subclass that mosaics more than one layer. > g) Are you planning to develop TINs an DEM Layers? How can I render a > grid dem? A grid DEM is just a GridCoverage. I don't have any plans for TINs now, but some other developer may have, I don't know. > h) Is your feature lock model pessimistic? Are you planning to consideer > optimistic locking and conflicts resolution? We are working to integrate > our DAO model with Hibernate. Hibernate uses optimistic locking. This is a question for data people. > i) Are you planning to work in TCP/IP based Spatial Server, with binary > communications? > GeoServer is great. But we think that for an enterprise environment > (like SDE) http is not a good protocol. It isnt connection oriented, and > it is a text based protocol (XML based). > We have developed a pilot of a spatial Server with same philosophy of > ArcSDE: > 1) Connection oriented. A client makes a connection, and connection > lives in server until client closes it. Server Connection is a thread > doing something like this: > boolean continue = true; > while (continue) { > try { > doWork(); > }catch (Throwable ex) { > continue = false; > }//catch > }//while > > And doWork() is something like this: > > String action = socket.readString();//thread is blocked here > String commadClassName = mappings.getCommandClassNameFor(action); > Command comand = commandFactory.createCommand(commandClassName); > Form form = mappings.getFormForComand(commandClassName,action); > ContextData context = new ContextData(sdeSocket);//Read params from socket > boolean checkPassed = form.validate(context); > Object[] results = null; > if (checkPassed) { > results = comand.execute(context, form); > String viewClass = mappings.getView(commandClassName, action); > ViewDispatcher dispatcher = > ViewDispatcherFactory.createViewDispatcher(viewClass); > dispatcher.renderView(results, socket); > } > > 2)Extensible (with a MVC architecture an dinamic linkage via XML) > > 3) Binary Communication. Now we are using a propiety protocol. But wed > love to a b-xml implementation... Are someone planning to release a > B-XML implementation? Is anyone interested in discuss this? > > 4) Bidirectional communications based in full-duplex sockets. Think in a > client making a zoom of all the world. It renders world's countrys while > it reads country's features from our server. If we don allow client to > finish zoom (making another zoom to canada, for example) with a full > duplex socket we neednt to close connection and open another one. > Instead, we read data from server by buckets (like fetch size of > Oracle), and when we complete a bucket, server waits for a control byte. > We send a cancel byte and server stops sending worlds countrys to > client, and start wait for another request. Nice. And I agree with you, Geoserver would never be as fast as this solution. The answer for your question may be provided by other people thought, I don't have plan on a ArcSDE clone thought I like the idea. Best regards Andrea Aime |