Chris,
This reply is really helpful - thanks. Note that I am sending this to our
nascent dev discuss list, which is probably where we should put all future
correspondence on GeoServer development. I want to start creating as much
of an institutional history as possible; plus I am trying to keep a
permanent public record of all the stupid things I say... On that topic...
Well, since we already have a Postgres SQL database that is holding the
geographic data, why wouldn't we be able to create another table and
store the data there? Granted, I'm not too familiar (yet) with how
Of course, I should have mentioned this as an option and for the short term
it is clearly the easiest thing to do for users. However, Postgres is more
of a pain in the ass to install and develop for than MySQL and is slower for
the sort of read-often/write-rarely crap we will be doing with the
configuration data. Since we hope to someday support many back-end
databases, I don't want to force users to install PostGIS no matter what -
in fact I have had some of our first potential users refuse to do this
already. So, this probably requires a phone call or meeting, since I want
to make the right choice, but I will probably shelve this until March and
after we release 1.0 using XML. I put this in the task tracker so we don't
forget.
Well, if this is an unsolved problem in Computer Science (please correct
any mistaken assumptions I may make), I should write a paper (and get
famous) as I was able to import GML into the old GeoServer without any
problems. Here's how I did it:
Tee hee. Yes, whenever you hear me use the phrase 'unsolved problem in
computer science,' it is probably time to put the waders on because the
bullshit is about to get real deep. 
However, I think I didn't make my
point clear enough, so let me try again with further hand waving. According
to one of my coworkers here who actually does know something about this
U.P.i.C.S. because he took class last year at Columbia on XML and database
design, the U.P.i.C.S. is: How do you automatically map arbitrary XML
schemas (hierarchical, semi-object data models:
http://www.w3.org/XML/Datamodel.html) into standard databases (relational
data model) and back out again? As you can tell, I don't really know much
about this, but I believe my friend because I can't see how to do the
mapping either.
So, in the excellent example you gave, you have a 'flat' schema with no
nested elements that easily maps into a single table in the database. Look
at this class:
http://geoserver.sourceforge.net/documentation/javadocs/org/vfny/freefs/serv
lets/utilities/PostgreSqlSchemaElement.html.
If you inspect the source, you will see that I have done something almost
identical, except in the opposite direction: mapping a 'flat' table into a
'flat' XML schema. However, GML is much more expressive than this and each
geometry element could have arbitrary numbers of sub or related elements and
lots of other weird constructs that are hard to automatically map directly
into relational databases - i.e. need lots of tables and foreign keys and
maybe even then you can't quite do it. This is what I mean, but I am
probably making too big a deal out of it because it is semi-academic until
people start supporting more complex data structures on the client side.
One caveat -- I don't know if this is compatible with the current table
definitions (I really doubt it).
I don't quite understand this; remember that table defs must be totally
arbitrary. So, there are no table defs in GeoServer other than what the
user defines for their own feature type data needs.
Importing a schema in the example above would not generate new tables,
rather it would just put the appropriate definitions in the Feature Type
table. If you are working with two schemas on the server that have
identically named types, you can distinguish the two by adding a field
with each entry that allows the database to know which schema definition
to use.
Got it - this is a good idea. I like your approach and someday soon I will
poach your code and fit it into the current incarnation of GeoServer. It
makes sense to be able to do the flat mapping in both directions; I just
didn't think of this myself. If you want to do the integration, also, feel
free. In fact, I just put this in the task tracker and assigned it to you!
I'll try to write a high level description so that we are all on the
same pages with respect to goals before charging out too much.
Sounds like a plan.
Ok, I have finally gotten FreeFS running. However, it is under Resin as
I couldn't figure out how to get it running under Tomcat. I'm tabling
the Tomcat plans at the moment, until I'm more familiar with the source
and layout.
Awesome. I now dub you: installation #2, since you are the first known
person to do this besides me. And WTF is up with Tomcat being so hard to
configure? I mean, we are smart guys, right? That's what I keep telling
myself at least...
Also, can you change my VFNY news subscription to be under
geoserver@anonymised.com instead of my Princeton address?
Done.
Cheers!
Rob