This page last changed on Jul 31, 2006 by cholmes.

After GeoServer 2.0 is completed, it really opens a lot of possibilities for the open source GIS world to compete directly with proprietary software. It is actually a small leap from 2.0 to a true Open Source Spatial Data Engine. GeoTools will continue to support more and more formats, especially as momentum around uDIG grows ? data formats added to uDIG are instantly available to GeoServer. The work on joins and decoupling data schemas from the backend makes it then very easy to 'spatialize' existing databases, just as ArcSDE does. As the open source java gis movement grows it will indeed become hard for proprietary software to keep up, as the features people need will start to roll in.

A key to make GeoServer truly compete will be very good central data management and caching. Being able to keep features in memory, and then write to file when the memory cache is full, with listeners to drop the cache when things are updated. It is probably worth looking into the Jboss POJO caching to handle parts of this. One very interesting tack to take would be to put an embedded Java database at the center of GeoServer. The newly open sourced Apache Derby database contributed by IBM looks quite promising, as it can be easily embedded in Java apps, and does a very good job at going from memory to disk. Perhaps as GeoServer 2.0 work is going on, someone could work on a SpatialDerby, combining the two in GeoServer 3.0. It also could be interesting to look into directly supporting the ArcSDE protocols, becoming a sort of Samba for Geographic information (Samba is a linux based file and print manager for Windows, which actually ends up outperforming Windows servers). And the great part would be that the modularized services would still be available ? the ArcIMS is already there, and you wouldn't have to pay anything more, you just download the WMS and WFS and start serving the data. With the J2EE design you could place them on different computers, all with the same central configuration. As for clients, uDIG and gvSIG, as well as any other client supporting OGC interfaces, would be able to use WFS-T protocols. We also could do some interesting things with GeoAPI, directly send Java features back and forth. With an embedded Derby Spatial this would introduce new, interesting workflows, as GeoServer would come with a complete spatial database, which users could just upload their work to, instantly sharing with others and presenting online. Basically the future is looking very bright, and we will get there eventually. We encourage you to join us directly, and help to bring that future to light sooner.

Document generated by Confluence on May 14, 2014 23:00