As such I will be making use of the following blog: http://how2map.blogspot.com/.

I would like to thank Java.net for hosting, and hope the spam comments problem abates.

Frank Hardisty asked: For projects the size and complexity of GeoTools and GeoServer, is there currently a viable alternative to Maven?

Is there an alternative to Maven

Good question - I think the alternative would be more organization on our part:

• less dependencies
• and to commit the jars into svn

• writing a lot more of our own software; and end up in a not invented here situation like many other projects.
• at the end of the day all we would be left with is a simple build

What I like about maven is the chance to look into some coverage tools (for example), notice that they support maven, and quickly try out a few by running maven a couple of times. I have to hand it to people like Justin and Martin who have gone ahead and made a few maven plug-ins for the community; I am so glad our build is not a mess of ant scripts, and hacks that only work on linux, and ... well lets say I have worked on a smaller project that took 40 mins to build.

On a related note I am stuck maintaining a simple build that does the exact same dependency management work (since it uses GeoTools jars) - the uDig application uses an ant script to suck down jar files from the maven repository. Maintaining this is a pain and we really wish we could make use of maven.

The uDig project is stuck between two evils; something called PDE Build which makes maven look like a cake walk; and Maven (who would solve our problems except that the eclipse foundation is a big pay to play mess).

Jody

PS. My rant here ends up being pro community; rather than pro maven

PPS. A cake walk is actually an American dance tradition; with the best dancer literally "taking the cake"

PPPS. There is a couple of Java Community Process module proposals going around trying to learn from both Spring, OSGi and the maven repository system]]> 2007-10-09T18:27:26Z 2007-10-09T18:27:05Z tag:weblogs.java.net,2007:/blog/jive/271.8399 2007-10-09T18:27:05Z

If you want to see how close these two are be sure to attend the presentation: WMS Performacne: Mapserver vs. Geoserver.

It is a good thing I got a sneak peek at the results, because I am going to be busy ...here are a couple of things to see out of the way of the main program.

Demo Theatre

Developer Gatherings

There are two places to hunt down the developer community and see them in action:

• Bird of a Feather Sessions; and
• Code Sprint.

In my last blog post I talked about GeoAPI and how we use it to define interfaces for a lot of the spatial goodness happening in the Java world. One of the constructs discussed was the interface for CoordinateReferenceSystem. This interface is implemented by a couple of projects:

• GeoTools
  
• JScience
  

JSR-275 defines a really amazing concept of "Unit of Measure" (as described in Fowlers Analysis Patterns Book). This idea is powerful, and allows you all kinds of runtime safety checks so that you do not (in the proverbially case) mix up meters and feet and fly into Mars by accident.

In JSR-275 they broke out Java Generics system and made a lot of this goodness into something the compiler can check for.

So why doesn't GeoTools use JSR-275

Problem is the reference implementation (also provided by JScience) is Java 5 only :-) So for the moment GeoTools community is hanging back so we can work with all those Java 1.4 J2EE projects that pay the bills.

JSR-108 Where art thou

Actually the GeoTools project still uses a units-0.1.jar provided by the earlier JSR-108. This earlier JSR-108 was withdrawn - and that seems to have scared the voting parties.

From the JSR #275 Units Specification JSR Review Ballot:

On 2005-06-09 Sun Microsystems, Inc. voted No with the following comment:
Sun is voting "no" on this JSR based on concern over whether there
is broad need for this JSR and concern that this is essentially
equivalent to an earlier JSR (108) which was previously withdrawn.

It is possible that this topic may eventually benefit from a JSR.
However, it is not yet clear that there is broad Java community interest
in a Java standard in this space. There appeared to be only fairly
limited community interest in JSR-108.

I would like to suggest that the submitters continue investigating and
developing their API as a standalone class library. Once they have more
experience and can demonstrate broader community interest, it may be
appropriate to launch a JSR.
- Graham

There are a lot of very similar comments, even the positive votes call into question the existence of JSR-275 based on the perception of JSR-108 as a failure.

Why Units Matter

Please be assured that the concept of a unit system is vital to using Java for scientific purposes. Even the old JSR-108 code is in day to day use around the world - in my projects it is used to explain how the world is round.

Be assured JSR-275 would be an instant success if it was not battling a community that is still bound by Java 1.4. The availability of JSR-275 will be added motivation for us to upgrade. The value and utility of JSR-108 is also holding us back; be assured that when we do upgrade the reference implementation of JSR-275 will be test from all kinds of angles.

GeoTools and Java 5 - now is the Time

GeoTools is tabling a proposal right now about when to upgrade to Java 5. The success of JSR-275 on July 8th will be instrumental in this decision.

We will do our best to upgrade to JSR-275 - The only other thing you can do to help is is to kick websphere (and others) into releasing a proper Java EE implementation. You will find that the scientific community, much like the rest of Java, is splintered between versions.

Units with generics is great, it makes for a better example of Generics pulling their weight in the Java language than the usual example of Collections.

And it includes one feature (out of many) of interest to this discussion: A GIS.

Perfect!

This is exactly what I want to see happen; GIS as a widget that can be rolled into your application de jour.

The actual widget is kind of fun; the data format makes use of Geography Markup Language (GML) to define its polygons and so on. Yes it is an Eclipse RCP application, and no they did not talk to us about using uDig. You can uDig in your own RCP applications - but what they have is nice and specific to their data format. They even have google earth integration - looks like they could of talked to GeoServer and saved some effort.

I assume there was just not enough time / energy / benefit to the developers to work with a larger community on this one. uDig offers an intergration platform so you can roll all kinds of data formats into the same projection and see it on the screen - making use of a number of open source projects to get the job done.

What do we have to work on?

There are several areas of neutral grounds for Java open source projects to meet, greet, and share common geospatial interfaces.

At a low technical level most projects are making use of the JTS Topology Suite to get their polygon game on. Sometimes they wrap the beast up in modern ISO Geometry clothing, and sometimes they just punt raw coordinates onto the screen until JTS is needed for actual work.

At a high level we are often working against the same file formats (shapefile, JPEG2000, etc..) and against the same web services (Web Feature Server, Web Map Sever).

It is in between where things get a bit messy. Geospatial projects often use the same concepts (Feature is something that can be drawn on a Map, A Map is made up of layers of features styled up and made to look pretty, etc...). Occasionally these concepts are based on a specification (the referencing specification describes where a coordinate end up on your map, the geometry specification defines what a surface is, that GML specification defines an XML file format for features, and so on...).

Basically the model is the same - why can't we share code.

How can we work together?

The GeoAPI project defines common interfaces for much of the middle ground. It even has a procedure for projects to collaborate together.

Here is an example: that idea of "Referencing" has a set of interfaces, and there are two implementations:

• Java 1.4: in the GeoTools project
  
• Java 5: in JScience project.
  

If you are building an application you can pick and choose.

It would be great if we could pull this off for some more concepts. The process is in place, but perhaps our approach (our sales pitch) has been wrong.

Why don't we work together?

One (bad) design trick you can play to get collaboration started is to present a design that is mostly right, and let others find and correct the mistake. By getting everyone to contribute it becomes much more of a shared property and of interest to all.

Currently we have been driving GeoAPI from mostly one view point - the specifications. This is easy to understand - since the specifications have all the hard naming choices figured out. However by starting with a specification, the process does not feel "open" to collaboration.

In practise the specifications always have mistakes, and collaboration is vital for success. I just wish I could make that point more: Got Java? Got Geography? GeoAPI needs you!

I wish we could stress community building as much as correctness.

Here is where our approach can be fixed: by saying "We should work together" we are being too timid - the statement is easy to agree to - but chances are it will never happen. Enthusiasm, funding and deadlines drive software here rather than good intentions.

We should work together on THIS?

So here is the statement I would like us to make (rather than working on something "abstract"). Let's work together on something specific.

What is a Map

I just want to capture the data model here, we can bust out different widgets to visualize the thing after.

A couple of suggestions:

• Have a look around and see what projects do in the wild
  
• GeoTools is sick of its representation (it does not do WMS layers) and would love to collaborate on this
  
• OpenJUMP may be in a similar situation?
  
• GeoWidgets would love to be the keeper of a Map widget
  
• OSGeo has a a SoC student working on a 3D widget
  

If we really get stuck on names - the file format for Open Web Context Document is around. I want to read in and display the result in a number of widgets. The file format is not finished yet (so we provide feedback if we see something we hate). Treat this as an opportunity not a constraint. Sample code exists in uDig to read the file format.

All the best and happy hacking.

I first ran into this problem with PostGIS (a set of spatial extensions for the PostgreSQL database). The oracle spatial license does not let you run benchmarks and publish. So the only thing I can do is tell you "it is really good". PostGIS is such a success that most spatial data wranglers check it out, and measure for themselves, before going further with Oracle.

Oracle does do somethings very well, the security model is awesome. With their "Free for Development" download they are even getting more open source love ... but until we can place that jdbc driver in a maven repository there will not be very many turn key open source oracle solutions.

FOSS4G Presentation Material

In todays GeoServer IRC meeting the subject of presentations for the Free And Open Source Software for Geoinformatics was on the agenda.

One thing the community is really proud of is how much GeoServer has improved in the last year. The community has been really brave, rewriting their raster support to the point it shines, and putting together a really nifty dispatch system in order to take on the monster that is WFS 1.1.

Of course all of that is technical and does not make a good presentation (except to other developers so it will be a good beer garden subject).

What does make a good presentation is performance. And this is where open source volunteers shy away from the legal mess that is benchmarking.

Specifically we can set up a nice chart comparing the usual open source subjects. This mostly means MapServer since we enjoy talking to Frank about GDAL performance.

But for the commercial offerings? Like a comparison with ArcIMS?

We did think of a couple of ways:

• Report the performance of some publicly available ArcIMS instance
  
• Run our performance test during the presentation (it would not be on the slides but the audience could see)
  

So what can you tell me? How good is GeoServer?

So here is the best idea we can offer you - if you want to know how insanely great GeoServer has become download the (open source) tool we used for testing and measure it yourself.

And just because we want you to come to FOSS4G - please attend our presentation (fingers crossed that it will be accepted) and learn where to download said performance testing tool.

You could also engage one of several consulting companies to produce a report for you.

If you do find out how good GeoServer is keep it on the hush hush.

To Review

CoordinateReferenceSystem world = CRS.decode("EPSG:4326"); // world lon/lat
CoordinateReferenceSystem local = CRS.decode("EPSG:3005"); // british columbia
        
FeatureSource road = store.getFeatureSource( "road" );

DefaultQuery query = new DefaultQuery( "road", Filter.INCLUDE, new String[]{ "geom", "name" } );       
query.setCoordinateSystem( local );
query.setCoordinateSystemReproject( world );
                
FeatureCollection features = road.getFeatures( query );

if (forcedCS != null)
    results = new ForceCoordinateSystemFeatureResults(results, forcedCS);
if (reprojectCS != null)
    results = new ReprojectFeatureResults(results, reprojectCS);

The Review

• FeatureCollection.getFeatureType() - returns the type of a the collection. Surprisingly collections are features as well. Makes sense if you consider that a feature is something that can be drawn on a map.
• FeatureCollection.getSchema() - is the type of the contents of the collection

Looking at the Solution

• ForceCoordinateSystemFeatureResults - this one just changes the FeatureType ... something we have already accomplished.
• ReprojectFeaureResults - takes an existing FeatureCollection and grinds through the data applying a MathTransform to each Geometry

Feature next = reader.next();
Object[] attributes = next.getAttributes(null);

for (int i = 0; i < attributes.length; i++) {
    if (attributes[i] instanceof Geometry) {
        attributes[i] = transformer.transform((Geometry) attributes[i]);
    }
}
return schema.create(attributes, next.getID());

this.transform = CRS.findMathTransform(originalCs,destinationCS, true);

Applying the Solution .. to AbstractFeatureSource? No

    public FeatureCollection getFeatures(Query query) throws IOException {
        FeatureType schema = getSchema();        
        String typeName = schema.getTypeName();
        
        if( query.getTypeName() == null ){ // typeName unspecified we will "any" use a default
            DefaultQuery defaultQuery = new DefaultQuery(query);
            defaultQuery.setTypeName( typeName );
        }
        else if ( !typeName.equals( query.getTypeName() ) ){
            return new EmptyFeatureCollection( schema );
        }
        FeatureCollection collection = new DefaultFeatureResults(this, query);
        if( collection.getDefaultGeometry() == null ){
            return collection; // no geometry no reprojection needed
        }        
        if ( query.getCoordinateSystem() != null ){
            collection = new ForceCoordinateSystemFeatureResults(collection, query.getCoordinateSystem() );        
        }
        if ( query.getCoordinateSystemReproject() != null){
            collection = new ReprojectFeatureResults(collection, query.getCoordinateSystemReproject() );                        
        }
        return collection;
     }

Applying the Solution to DefaultFeatureResults

        CoordinateReferenceSystem origionalCRS = origionalType.getDefaultGeometry().getCoordinateSystem();
        if( query.getCoordinateSystem() != null ){
            origionalCRS = query.getCoordinateSystem();
        }
        try {
            transform = CRS.findMathTransform( origionalCRS, cs, true);
        } catch (FactoryException noTransform) {
            throw (IOException) new IOException("Could not reproject data to "+cs).initCause( noTransform );
        }  

    public FeatureReader reader() throws IOException {
        FeatureReader reader = featureSource.getDataStore().getFeatureReader(query,
                getTransaction());
        
        int maxFeatures = query.getMaxFeatures();
        if (maxFeatures == Integer.MAX_VALUE) {
            return reader;
        } else {
            return new MaxFeatureReader(reader, maxFeatures);
        }
    }

• ReprojectFeatureIterator ... utility class used when your collection is memory based
• ReprojectFeatureReader ... perfect!

    public FeatureReader reader() throws IOException {
        FeatureReader reader = featureSource.getDataStore().getFeatureReader(query,
                getTransaction());
        
        int maxFeatures = query.getMaxFeatures();
        if (maxFeatures != Integer.MAX_VALUE) {
            reader = new MaxFeatureReader(reader, maxFeatures);
        }        
        if( transform != null ){
            reader = new ReprojectFeatureReader( reader, schema, transform );
        }
        return reader;
    } 

• An example of how to support reprojection directly as part of your FeatureCollection (ie use of ReprojectFeatureReader or ReprojectFeatureIterator wrappers)
• An example of how to support reprojection after the fact .. modify your getFeatures( Query method ) to  use ReprojectFeatureResults (or its colleciton based ReprojectingFeatureCollection)

Almost done

Ignore the Problem

public DefaultFeatureResults(FeatureSource source, Query query) {
    this.featureSource = source;        
    FeatureType origionalType = source.getSchema();
    
    String typeName = origionalType.getTypeName();        
    if( typeName.equals( query.getTypeName() ) ){
        this.query = query;
    }
    else {
        this.query = new DefaultQuery(query);
        ((DefaultQuery) this.query).setTypeName(typeName);
    }
    ... handle query
}

Exceptionally Annoying

• Failure during rendering sucks; you get an empty screen. Much nicer to see the data that worked ... and then sift through the LOG messages to discover why your rivers did not show up.
• Failure during long running process hurts; GIS data is large usually you will need to try
• Something quick and simple for 80% of the work
• Break out something harder for 15%
• 4% for data cleaning. Perhaps it was collected wrong (perhaps the lines are invalid .. or were made so by loss of percision)
• 1%... and then you are down to a manual process

public FeatureCollection getFeatures(Query request) throws IOException {
    String typeName = featureType.getTypeName();

    if ((request.getTypeName() != null) && !typeName.equals(request.getTypeName())) {
        throw new IOException("Cannot query " + typeName + " with:" + request);
    }
    if (request.getTypeName() == null) {
        request = new DefaultQuery(request);
        ((DefaultQuery) request).setTypeName(featureType.getTypeName());
    }
    return new JDBCFeatureCollection(this, request);
}

Or be correct

public FeatureCollection getFeatures(Query query) throws IOException {
    FeatureType schema = getSchema();        
    String typeName = schema.getTypeName();        
        
    if( !typeName.equals( query.getTypeName() ) ){
        return new EmptyFeatureCollection( schema );
    }
    else {
        return new DefaultFeatureResults(this, query);    
    }        
}

How Query is Handled

public FeatureCollection getFeatures(Query query) throws IOException {
    FeatureType schema = getSchema();        
    String typeName = schema.getTypeName();
    
    if( query.getTypeName() == null ){ // typeName unspecified we will "any" use a default
        DefaultQuery defaultQuery = new DefaultQuery(query);
        defaultQuery.setTypeName( typeName );
    }
    
    if( !typeName.equals( query.getTypeName() ) ){
        return new EmptyFeatureCollection( schema );
    }
    else {
        return new DefaultFeatureResults(this, query);    
    }        
}

Unimplemented functionality - how did this Happen?

Unimplemented functionlaity - why Fix it?

• In our Renderer .. I saw this back in November when we hooked up Expression (a query langague) so that POJOs (ie normal objects) could be drawn onto a map
• In other applications .. GeoServer noticed this problem and talked about it in last weeks IRC meeting
• In other applications .. uDig developers noticed and hacked around the problem so quickly they forgot to report it

Broken - using Query to Reproject

FeatureSource source = dataStore.getFeatureSource( "road" );
FeatureCollection features = source.getFeatures();

FeatureSource source = dataStore.getFeatureSource( "road" );
DefaultQuery query = new DefaultQuery( "road, Filter.INCLUDE );
FeatureCollection features = source.getFeatures();

CoordinateReferenceSystem world = CRS.decode("EPSG:4326"); // world lon/lat
CoordinateReferenceSystem local = CRS.decode("EPSG:3005"); // british columbia
        

FeatureSource road = store.getFeatureSource( "road" );
DefaultQuery query = new DefaultQuery( "road", Filter.INCLUDE, new String[]{ "name" } );
        
query.setCoordinateSystem( local ); // FROM, optional, will ignore actual data and force CRS
query.setCoordinateSystemReproject( world ); // TO, optional, will reproject data into CRS
                
FeatureCollection features = road.getFeatures( query ); // will reproject the features        

• setCoordinateSystem() - changes the "Metadata", the information will be returned as is (same values) but the meaning will be changed - the FeatureType will report back that the information is in the provided CRS
• setCoordianteSystemReproject() - changes the actual "Data", in addition to changing the FeatureType the actual data values will be reprojected and the result returned

Solution? The code always knows...

FeatureType origionalType = source.getSchema();

CoordinateReferenceSystem cs = null;
if (query.getCoordinateSystemReproject() != null) {
    cs = query.getCoordinateSystemReproject();
} else if (query.getCoordinateSystem() != null) {
    cs = query.getCoordinateSystem();
}
schema = DataUtilities.createSubType(origionalType, query.getPropertyNames(), cs, query.getTypeName(), null);

if (forcedCS != null)
    results = new ForceCoordinateSystemFeatureResults(results, forcedCS);
if (reprojectCS != null)
    results = new ReprojectFeatureResults(results, reprojectCS);

First of All the Test Case

Using a Debugger with Binary Search

DefaultFeatureResults Constructor

public DefaultFeatureResults(FeatureSource source, Query query) {
    this.featureSource = source;
    String typeName = source.getSchema().getTypeName();

    if( typeName.equals( query.getTypeName() ) ){
        this.query = query;
    }
    else {
        this.query = new DefaultQuery(query);
        ((DefaultQuery) this.query).setTypeName(typeName);
        ((DefaultQuery) this.query).setCoordinateSystem(query.getCoordinateSystem());
        ((DefaultQuery) this.query).setCoordinateSystemReproject(query.getCoordinateSystemReproject());

    }
}

cholmesny     public DefaultFeatureResults(FeatureSource source, Query query) {
cholmesny         this.featureSource = source;
     jive         String typeName = source.getSchema().getTypeName();
  groldan
     jive         if( typeName.equals( query.getTypeName() ) ){
  groldan             this.query = query;
     jive         }
     jive         else {
    aaime             this.query = new DefaultQuery(query);
    aaime             ((DefaultQuery) this.query).setTypeName(typeName);
    aaime             ((DefaultQuery) this.query).setCoordinateSystem(query.getCoordinateSystem());
    aaime             ((DefaultQuery) this.query).setCoordinateSystemReproject(query.getCoordinateSystemReproject());
     jive         }
cholmesny     }

    public DefaultQuery(Query query) {
      this(query.getTypeName(), query.getNamespace(), query.getFilter(), query.getMaxFeatures(),
          query.getPropertyNames(), query.getHandle());
      this.sortBy = query.getSortBy();
      this.coordinateSystem = query.getCoordinateSystem();
      this.coordinateSystemReproject = query.getCoordinateSystemReproject();
    }

DefaultFeatureResults getSchema()

    public FeatureType getSchema() {
        if (query.retrieveAllProperties()) {
            return featureSource.getSchema();
        } else {
            try {
                return DataUtilities.createSubType(featureSource.getSchema(),
                    query.getPropertyNames());
            } catch (SchemaException e) {
                return featureSource.getSchema();
                //throw new DataSourceException("Could not create schema", e);
            }
        }
    }

public DefaultFeatureResults(FeatureSource source, Query query) {
    this.featureSource = source;        
    FeatureType origionalType = source.getSchema();
    
    String typeName = origionalType.getTypeName();        
    if( typeName.equals( query.getTypeName() ) ){
        this.query = query;
    }
    else {
        this.query = new DefaultQuery(query);
        ((DefaultQuery) this.query).setTypeName(typeName);
    }
    CoordinateReferenceSystem cs = null;        
    if (query.getCoordinateSystemReproject() != null) {
        cs = query.getCoordinateSystemReproject();
    } else if (query.getCoordinateSystem() != null) {
        cs = query.getCoordinateSystem();
    }
    try {
        if( cs == null ){
            if (query.retrieveAllProperties()) { // we can use the origionalType as is                
                schema = featureSource.getSchema();
            } else { 
                schema = DataUtilities.createSubType(featureSource.getSchema(), query.getPropertyNames());                    
            } 
        }
        else {
            // we need to change the projection of the origional type
            schema = DataUtilities.createSubType(origionalType, query.getPropertyNames(), cs, query.getTypeName(), null);
        }
    }
    catch (SchemaException e) {
        LOGGER.log( Level.WARNING, "Could not change projection to "+cs, e );
        schema = null; // client will notice something is amiss when getSchema() return null
    }
}

• That SchemaException is being gobbled up; the origional code just "faked it" by using the origionalSchema; this would result in data being returned, with no indication that it was not as asked for!

How would you answer a question like that? We all know the default answers, they form mantras for the open source movement. Things like many eyeballs just don’t seem that relevant when you are working in a niche like GIS (where data is king and programs are often “write once, run once”).

So why donate your code to GeoTools?

Here is my answer:
1. Do you expect others to contribute "plug-ins" or additional functionality to your work?

If so donating your API to an open source project is a great way to slurp up additional functionality. The OpenLS spec defines the ability to look up addresses, this is an ‘open ended problem’ (where 100% success is not possible) so using an open ended solution such as a plug-in mechanism combined with community involvement would really shine.

2. Donating the implementation allows you to share your maintenance cost with others.

This is especially important when your implementation is defined against a specification that is going to be changing in the future. . The future is risky; share the risk (and work) with others.

Cameron responded with the other possibility:
3. Is someone else planning to write an OS version of your code? Thus removing the value from selling.

That would be the stick.

The result of this meeting is just now been made available:

• WMS_Tiling_Client_Recommendation
  

While this is an exciting concept, the excitement has spread to the media - in this case Directions Magazine: OSGeo Offers Up a Tiling Specification

The article explores the idea of OSGeo as a standards body, and I thought I may offer a clarification in this specific instance.

The tiling "specification" is currently a bunch of hackers bashing away at the problem. Standardization comes later, the document will be submitted to the OGC where I imagine it will be treated as an extension to WMS (much like the SLD specification).

It should be noted that this has been done carefully at a technical level, the requests made conform to the WMS specification. It was very tempting to do something closer to nasa worldwind where tiles are asked for row/col.

I always respect a standard that is backed by an implementation, more so when several implementations are available. The fact that OSGeo plays hosts to open source projects, that by definition need to work together, provide a great environment for collaboration in this manner.

This is the same approach used by the OGC for their interoptability experiments. Please view this tiling experiment in the same manner, the documents are not offical but we may learn enough to inform a standard.

Aside: The OGC does provide a nice venue for "Open standards"; personally I find their direct use of ISO standards is starting to "close" the door. A house with an open door, does no good if the front gate is locked.

• three new acquaintances
• gain an in site, lose a preconception
• explore the next big thing

But First

• Most Improved Player Award - Microsoft Cooperation had a horrible showing at OOPSLA 2004 where they misread their audience, this year they are taking care of the student volunteers who make the event a success. I tracked down at least one of their representatives personally, way to go guys.

• Most Impressive Use of Multimedia - Ron and Richard presented an amazing production of multi media tag team stage craft along the subject of "Conscientious Software" with references to Eric Clapton and Micro-Biology feedback systems. Fun stuff.
• Cool - The KeyNote bringing together a feedback from poetry and expression  to the massively multiplayer experience. And heck 1/f pink noise was around in the form of water and wind chimes to close the gap with music as an expression of nature.

New Acquaintances

Lose a Preconception

1. Natural Resting State - or the concept of "Harmony". The is an under current of "fear" present in a lot of the talks and material - how can stability be achieved?  Suggestions buffet from all sides, several talks searching to nature. A goal of 60% test coverage looks rather sad, if you are comparing against nature where QA functions seem to account for more of the material for life then actual function. The Ultra people tend to agree as they consider failure as always part of the system, and change as a continual aspect of the environment.
2. Group Action - a local resonance where a bunch of objects respond to the same stimulus. This is slightly different then the emergent behavior, or the web 2.0 quest to turn mob behavior into money.  The picture example was a table of party goers pointing to their cake at the other end of the picture, or a group of gossips laughing at a man who was unable to pay his bill (both of which I missed on first inspection)
3. Object and Field - and this is the nice one for me. By paying attention to the whole, the system rather then the parts becomes visible. If I break into a discussion of negative space or something you can blame a multi media high.

Explore The Next Big Thing

Design Patterns Reception and Panel

• data replication
• tacking status for a quality of service estimate
• cache the results (ie tile schemes)
• and the ever present request for metadata

Client Solution One: Use more WMS Servers

Client Solution Two: Sharing a Vision

Client Solution Three: Get Tricky

• prior knowledge: simple pattern matching can account for GeoServer and MapSever WMSLayer to FeatureType association
• included metadta:  the description of a WMSLayer can point off to an external data URL, if we recognize that as a WFS link ...
• external metadata :given an interesting CSW2  profile to hit we can make use of associations tracked by a third party

What is Next?

GeoNetwork Presentation

GeoTools Presentations

• GeoTools Getting Standards to Work (with slides)
• GeoTools Working on Standards (with slides)

uDig Presentation

• uDig Desktop Application Framework (with slides)

• Both projects started at the same time
• They have different licenses (reflecting the different roles they wish to play)
• Differences in design goals

DivaGIS Talk

gvSig Talk