[tdwg-tapir] Conversation with people from the Geoserver software.

[Javier de la Torre]

Hi all,

I do not know if I should post this here but I felt this may be of  
interest of everybody working in the protocol.
I was doing some questions about the configuration of Geoserver to  
provide a WMS and WFS service that I am creating, I think you all  
know about it. The mapping configuration between the database and the  
GML for the WFS service inside Geoserver is quite limited, but there  
are some people working on ways to improve it. I introduced a little  
bit what we are doing and they answer all this...

I hope it is of your interest... if anybody want to join the  
discussion go and subscribe to geoserver-devel at lists.sourceforge.net

Javi.

Begin forwarded message:

> From: Chris Holmes <cholmes at openplans.org>
> Date: 23 de noviembre de 2005 20:55:29 GMT+01:00
> To: Javier de la Torre <jatorre at gmail.com>
> Cc: geoserver-devel at lists.sourceforge.net, rob at socialchange.net.au
> Subject: Re: [Geoserver-devel] Re: [Geoserver-users] schema.xml file
>
> Quoting Javier de la Torre <jatorre at gmail.com>:
>
>> Hi Chris,
>>
>> Interesting discussion!
>>
>>>> In our mapping language (we call it
>>>> CMF, concept mapping file) comparable to schema.xml file we allow
>>>> complicate mappings with filters, conditional mappings and things
>>>> like that. I suppose is pretty much the same thing you are
>> thinking.
>>> Interesting.  It could be interesting to try to sync up the work
>> we're
>>> both doing.  I don't like everyone reinventing the wheel for
>> mapping
>>> files, but I don't know of anyone else really doing them.  Perhaps
>> we
>>> could try to use the same file format between our projects.  The
>>> 'filters' that we make use of our primarily OGC Filters - their
>>> representation of a where statement.
>>>
>>> Short (rough) overview here:
>>> http://udig.refractions.net/confluence/display/GOWS/Querying+data
>>> +using+%27Filter%27
>>> and full spec is here:
>>> http://portal.opengeospatial.org/files/?artifact_id=8340 (pdf)
>>
>>
>> Well, Ok, let's go in parts.
>> What we are working is in an HTTP-XML protocol to allow dynamic
>> queries to heterogeneous databases and get results in XML compliant
>> to whatever XML schema they have mapped their databases... (puff this
>> may not be the best description of it...). In our community (TDWG,
>> Taxonomic Database Working Group, a very little OGC like
>> standardization group) there are two protocols for doing that, Digir
>> and bioCASe, and now we are merging them into a new one called TAPIR.
>> There will be two implementations of this protocol. The protocol,
>> very much like the WFS protocol, is still under discussion in a wiki
>> page http://ww3.bgbm.org/protocolwiki/FrontPage.
>>
>> Actually the WFS protocol was reviewed when creating this new
>> protocol because it was considered a possible solution to our
>> problems. If you take a look at our capability operation is very
>> likely to WFS one, and the filtering in a query is also very similar
>> to the one you pointed me (because we also get inspired by it!).
>>
>> For this protocol we are creating there will be two reference
>> implementations, pywrapper in python, and Digir 2 in Java and RDF
>> based.
> Interesting.  Looking at the schemas it actually looks a bit closer to
> catalogue than WFS:
> http://portal.opengeospatial.org/files/?artifact_id=5929&version=2
> Unfortunately it's not as solid of a spec, and there aren't any good
> open source reference implementations.
>
> I wonder if it'd be possible to get some of your specs to line up more
> with OGC ones, and vice-versa.  Because it'd be really nice to be able
> to share code and implementations.  Like if it was possible to do just
> a few extensions to WFS for your needs, then you could just contribute
> to GeoServer, and the core would be stronger for all.  And people  
> could
> use the same parsing tools on both GML and your schemas, and the same
> clients to communicate back and forth.  I'm not sure how practical any
> of this actually is, but I _hate_ reduplication of work, and it just
> seems at the core we're doing a lot of the same stuff.
>
> The Catalogue spec has a good bit on a common query language, if you
> were to support that, and the same XML filters for example, then we
> could share code with GeoTools.
>
>>>
>>>
>>> We already had an implementation of them in GeoTools, since we're
>> OGC
>>> focused, so they made logical sense to do the mappings (correct me
>> if
>>> I'm wrong here Gabriel).  A nice thing about them is that we
>> already
>>> have most of the code written to 'unpack' them, that is if the back
>>> end
>>> data format can perform the filter, then we turn it into the SQL
>> (or
>>> whatever query language it might use).  So we should be able to get
>>> good performance out of the mappings, since where possible it's
>> passed
>>> to the backend.  But the nice thing is that we _can_ do it on
>>> anything,
>>> since there's Java code for it all, so Shapefile supports all
>> filters
>>> as well.
>>>
>>
>> Uhm... I do not understand this totally...
>> You mean that implementing a more intelligent mapping will let you
>> create dynamically SQL statements that you can use for filtering
>> based on the query filter? I feel I may be mixing everything...
>>
>> In our case we describe the database structure and we map the
>> database to the different schemas that we want to share the data in.
>> When someone do a query the wrapper read this configuration file and
>> figure out the where clause to filter the data in the SQL statement.
>> Then depending on the xml schema that is requested as a response it
>> selects the necessary information from the database to populate an
>> XML instance of this XML schema.
> Yeah, we do a similar thing, I guess the point of difference is that
> we're not always dealing with databases, so we're not always able to
> turn the filter into SQL, so we do so in Java code.
>
>>
>> Well, in reality it is a little bit more complicate to give the
>> mapping of the database-schema the necessary information to create
>> correct xml documents... Unfortunately an XML schema can validate
>> many different XML documents that looks completely different...
>>
>>>
>>>> I am working also
>>>> for a European project called Synthesys and I was planning to get
>> in
>>>> contact with the INSPIRE project in the near soon when I get more
>> OGC
>>>> knowledge :)
>>> Excellent.  If you want some contacts I know at least one good one.
>>>
>>
>> Yes! that would be great... I feel is a shame I am not in contact
>> with them when I am aiming at providing GIS services in a european
>> level...
> Ok, I'll let you know.
>
> And the thing I don't quite understand, how does the geographic stuff
> relate to the work you're doing on the spec?  Like are you planning on
> geographic stuff as part of it?  Or would you set up a database with
> both a TAPIR interface and a WFS interface?
>
>>
>>>>
>>>> What you are planning to do with complex mappings looks quite
>> similar
>>>> to the problem that we are trying to solve too. As I described we
>>>> have a wrapper tool to make possible to connect heterogenous
>>>> databases to a network where we can query them using a standard
>>>> protocol (TAPIR and BioCASe before), the results from the
>> providers
>>>> come in XML following a certain "conceptual schema" (what you call
>>>> application schema). Maybe we should have a talk and I will show
>> you
>>>> how are we doing things and you may get some ideas...
>>> Yeah, that could be good.  I don't know how far in to things you
>> are,
>>> but note that a WFS doesn't _have_ to do geometric objects.  Like
>> it
>>> could theoretically not return any GML at all, just XML.  I don't
>> know
>>> if that's the route to go, but it might weirdly be worthwhile to
>> just
>>> sync your effort up with GeoTools/GeoServer, since we would both
>>> benefit from more users and use cases.  But yeah, at the very least
>> it
>>> sounds like we're working on very similar problems, and can learn
>> what
>>> works and what doesn't, even if it doesn't make sense to share at
>> the
>>> coding level.
>>>
>>
>>
>> As I said before when we were discussing our protocol we took a look
>> at available protocols and one of those was WFS. I was not resposible
>> for that and I do not know the exact reason why it was discard (it
>> should be in the protocol review uhmm). But... is it possible with
>> WFS to do paging? I mean... in our case someone retrieve ten
>> "features" and then want to retrieve the next 10...
> No WFS does not currently do paging, but I actually don't think  
> that not
> currently meeting all your capabilities is a good enough reason to
> reject a spec.  Because it wouldn't be very hard to add a 'paging'
> capability to a WFS.  I mean, make a schema that extends WFS a bit,  
> for
> paging, make a reference implementation, and make it your official
> thing, and could even try to get it rolled back into the OGC specs.  I
> quote I quite like about standards is this:
>
> 'This tinkering with the [standardized] protocol, however, is not an
> empirical fact showing the limits of standardization in practice.  
> We do
> not point at these instances in order to demonstrate the ‘resistance’
> of actors to domination. Rather, we argue that the ongoing
> subordination and (re)articulation of the [standardized] protocol to
> meet the primary goals of the actors involved is a sine qua non for  
> the
> functioning of the [standardized] protocol in the first place.'
> Timmermans and Berg (1997: p. 291.)
>
> The point is you _should_ take a standard and improve it to your  
> needs,
> the point of standards is a basis to meet further needs.  And if you
> start with a standard, it's much, much easier to build upon lots of
> other work that's gone before.  Like if it's super similar to WFS,  
> then
> there could easily be both open source and commercial implementations
> of your spec made.
>
> I think Catalogue actually does have a concept of paging.  It's  
> concepts
> could probably be applied to WFS.  At the GeoTools level Jody is doing
> some work now for a Random Access API, which could make paging quite
> easy.
>
> But it looks like you're already too far along to really switch paths,
> and I'm not sure if the OGC specs would hold up to all your needs,  
> even
> expanding them where appropriate.
>
>>
>>
>>>> At the end seems everybody is working on the same problem, the
>>>> mapping of relational databases to XML schemas...
>>> Yeah, there's a lot out there, and a lot of different approaches,
>>> and it
>>> feels silly to roll so much of your own.  But many are lacking in
>>> different ways.  We're hoping with our approach to eventually be
>> able
>>> to sync up with other more generic things.  We looked into using
>>> Hibernate to do the object-relational mapping, but Rob needed to be
>>> able to control the SQL select statements, so you could derive your
>>> mapping from the results of a select statement, which hibernate
>> just
>>> doesn't let you.  And we wrote a straight SAX producer to stream
>> out
>>> GML, since at the time there were no good, fast object -> XML
>>> producers
>>> that allowed you real flexibility, since we have to deal with
>>> arbitrary
>>> Features, of arbitrary complexity, can't define the schema
>> beforehand.
>>> There are solutions now, and I think our next generation
>>> parser/producer makes of JAXB.  But yeah, working with Geographic
>>> Information we hit a lot of the big problems early, since the
>> datasets
>>> so quickly get huge.
>>>
>>
>> Yes, in our case this is an issue... we have to be able to page
>> trough datasets because even the fastest wrapper in the world will
>> not be able to retrieve 1 million features full of properties at
>> once... that's why we have paging.
>> One could thing we are trying to implement, for example, is that the
>> user is able to send the structure, the "complex_type", in an XML
>> schema fragment specifying the result formats he want the data to be
>> responded. There is a two step-mapping going here but I do not want
>> to get long now...
> That's really interesting, I could see that being very useful from a
> WFS/GML perspective as well:
>
> In OGC there's this concept of a Feature Portrayl Service, that  
> takes a
> WFS and an SLD, which is an XML language to specify how to 'style' a
> map, what the image should look like, and returns an image.  It's
> similar to a WMS, but sort of fully virtual, since nothing really sits
> on the server.
>
> It'd be very interesting to see such a thing for full GML, it would  
> take
> a WFS and a Mapping file as arguments, and perform the mapping,
> returning the result as GML, a sort of virtual WFS.  So if someone  
> else
> put their data up as WFS, but didn't bother to get it into a well  
> known
> schema, then you could just do it yourself.
>
> When we get the Complex Feature stuff sorted out in GeoServer this  
> type
> of thing shouldn't be all that hard.  We already support WFS as a
> DataSource (in addition to a number of databases and file formats),  
> and
> then we'd just need to define a mapping file.
>
> It seems like it'd be _really_ nice to have a common spec for the
> 'mapping file' we're talking about, how you apply filters and whatnot
> to go from one format/schema to another.  Rob, any thoughts about  
> that?
>  We're just kind of rolling our own this round, right?  It could be a
> cool win to have clients be able to choose the schema they want to  
> view
> data in, and just connect to a WFS supplying their chosen mapping.
>
>>
>> The project web page of one of this implementation is at http://
>> ww3.bgbm.org/tapir and if you want to see a data provider in action
>> you can go to http://ww3.bgbm.org/tapirwrapper/
> Looks cool.
>
> best regards,
>
> Chris
>
>
>>
>> Best regards,
>>
>> Javier.
>>
>>
>>> best regards,
>>>
>>> Chris
>>>
>>>
>>>>
>>>> Javier.
>>>>
>>>>
>>>>
>>>> On 23/11/2005, at 8:23, Chris Holmes wrote:
>>>>
>>>>> Actually, Javier, you're getting into the bleeding edge of
>>>> GeoServer,
>>>>> and you actually understand how WFS and GML _should_ work
>>>> perfectly.
>>>>> Rob has been pushing these types of things for awhile, and just
>>>>> recently managed to get a lot of the ideas in GeoServer as
>> working
>>>>> code
>>>>> with Gabriel.  The schema.xml files were not about actually
>> mapping
>>>>> your GML to different types, they were just kind of surface level
>>>> ways
>>>>> of renaming things.  The problem of actually getting names to map
>>>> back
>>>>> and forth, to perform filters on them, and more, is much more
>>>> complex.
>>>>>
>>>>> The problem is the code is on a branch, like Gabriel just
>> announced
>>>> it
>>>>> last week, and there will still be bugs, and there's lots of
>>>>> documentation to write.  But we would love to have you as a user
>>>>> testing it out.  Indeed your intended schema is pretty simple
>>>> compared
>>>>> to the complexity of what we're hoping to support.
>>>>>
>>>>> See the 'proto-documentation' (really just a place holder) here:
>>>>>
>>>> http://docs.codehaus.org/display/GEOSDOC/Complex+Feature
>>>> +Documentation
>>>>>
>>>>> As for MySQL, if you're using the MySQL module you need to have
>>>> your
>>>>> points stored as Geometries, see:
>>>>> http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions-in-
>>>>> mysql.html
>>>>> (it's available in 4.1 as well).  As for improvements from 4.1 to
>>>> 5.0,
>>>>> I haven't tried out 5.0, but looking at the docs there appears to
>>>> be
>>>>> nothing new, the support overall is pretty poor, I'd recommend
>>>>> upgrading to PostGIS asap.
>>>>>
>>>>> If you really want to define your MySQL table as just x,y
>>>> coordinates,
>>>>> Rob made a Geometryless module that will work, but we don't
>>>> currently
>>>>> include it with GeoServer.  I believe Gabriel upgraded it though
>> in
>>>>> his
>>>>> latest work.
>>>>>
>>>>> best regards,
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>> Quoting Justin Deoliveira <jdeolive at unknown-road.com>:
>>>>>
>>>>>> Hi Javier,
>>>>>>
>>>>>> So what you need is the wfs to serve up gml that conforms to
>> your
>>>>>> application schema. After you add your data store and feature
>> type
>>>> to
>>>>>> geoserver (via the config gui), your feature type will contain
>>>>>> attributes with the default types. You can customize the types
>>>> with
>>>>>> the
>>>>>> feature type editor. There are some docs on how to do this here.
>>>>>>
>>>>>> http://docs.codehaus.org/display/GEOSDOC/FeatureType+Config
>>>>>>
>>>>>> Note the part about changing the type of an attribute to an xml
>>>>>> fragment.
>>>>>>
>>>>>> Unfortunatley I dont know much about mysql, and even less about
>>>> its
>>>>>> spatial extension. However I am sure someone else will be able
>> to
>>>>>> help
>>>>>> with that. And questions about mysql could probably be best
>>>> answered
>>>>>> on
>>>>>> the geotools devel and user lists. I would try repositing those
>>>>>> questions there.
>>>>>>
>>>>>> If you have any more questions dont hesitate to ask.
>>>>>>
>>>>>> Justin
>>>>>>
>>>>>>
>>>>>> Javier de la Torre wrote:
>>>>>>> Hi Justin,
>>>>>>>
>>>>>>> Thanks for your answer.
>>>>>>> Some background. I am using MySQL right now as a DataStore (but
>>>>>> also
>>>>>>> planning to go for PostGIS). In my database I have a table
>> where
>>>> I
>>>>>> have
>>>>>>> records of specimens (plants) with information like their name,
>>>>>> who
>>>>>>> identified them, when they were collected, etc. Also I have in
>>>> the
>>>>>> same
>>>>>>> table coordinates of the location where these plants where
>>>>>> collected.
>>>>>>>
>>>>>>> My idea is to create a WFS service to provide the points where
>>>> the
>>>>>>> specimens where collected together with the other information.
>> We
>>>>>> have
>>>>>>> some kind of standards about how all this information must be
>>>>>>> described. The idea is to create a GML application schema where
>>>> we
>>>>>>> describe the specimens using our own "concepts" (like
>>>> CatalogNumber
>>>>>>  and
>>>>>>> things like that) and the location of the specimen using a
>>>>>>> gml:PointPropertyType.
>>>>>>>
>>>>>>> If I let Geoserver create automatically the schema for me I get
>>>>>>> something like this:
>>>>>>>
>>>>>>> ----------
>>>>>>> <xs:complexType name = "specimens_Type" >
>>>>>>> <xs:complexContent>
>>>>>>> <xs:extension base = "gml:AbstractFeatureType" >
>>>>>>> <xs:sequence>
>>>>>>> <xs:element type = "xs:string" minOccurs = "1" name =
>>>>>> "SpecimenGUID"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:string" minOccurs = "0" name =
>>>>>> "ProjectTitle"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:string" minOccurs = "0" name =
>>>> "BiotopeText"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:dateTime" minOccurs = "0" name =
>>>>>>> "CollectingISODate" nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:string" minOccurs = "0" name =
>>>>>> "LocalityText"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:string" minOccurs = "0" name =
>>>> "CountryName"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:string" minOccurs = "0" name = "Notes"
>>>>>> nillable
>>>>>>> = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:int" minOccurs = "0" name =
>>>>>> "AltitudeLowerValue"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "xs:string" minOccurs = "0" name =
>>>> "coordinates"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> </xs:sequence>
>>>>>>> </xs:extension>
>>>>>>> </xs:complexContent>
>>>>>>> </xs:complexType>
>>>>>>> -------------
>>>>>>>
>>>>>>> But I would prefer to get something like:
>>>>>>>
>>>>>>> -----------
>>>>>>> <xs:complexType name = "specimens_Type" >
>>>>>>> <xs:complexContent>
>>>>>>> <xs:extension base = "gml:AbstractFeatureType" >
>>>>>>> <xs:sequence>
>>>>>>> <xs:element type = "my_ns:GUID" minOccurs = "1" name =
>>>>>> "SpecimenGUID"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "my_ns:ProjectTitle" minOccurs = "0" name =
>>>>>>> "ProjectTitle" nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "my_ns: BiotopeText" minOccurs = "0" name =
>>>>>>> "BiotopeText" nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "my_ns:dateTime" minOccurs = "0" name =
>>>>>>> "CollectingISODate" nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "my_ns:string" minOccurs = "0" name =
>>>>>> "LocalityText"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "my_ns:string" minOccurs = "0" name =
>>>>>> "CountryName"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "my_ns:string" minOccurs = "0" name =
>> "Notes"
>>>>>>> nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "my_ns:int" minOccurs = "0" name =
>>>>>>> "AltitudeLowerValue" nillable = "true" maxOccurs = "1"  />
>>>>>>> <xs:element type = "gml:PointPropertyType" minOccurs = "0" name
>> =
>>>>>>> "coordinates" nillable = "true" maxOccurs = "1"  />
>>>>>>> </xs:sequence>
>>>>>>> </xs:extension>
>>>>>>> </xs:complexContent>
>>>>>>> </xs:complexType>
>>>>>>> ----------------
>>>>>>>
>>>>>>> And by the way... how do I have to define the coordinates in my
>>>>>> MySQL
>>>>>>> table so that Geoserver understand them as Points in gml? In
>> the
>>>>>> case
>>>>>>> of PostGIS is this done automatically?
>>>>>>>
>>>>>>> A final question... I do not find any documentation about the
>>>>>> spatial
>>>>>>> capabilities of MySQL 5, do you know if there is any
>> improvement
>>>>>> from
>>>>>>> what it was available already in 4.1?
>>>>>>>
>>>>>>> I am new to OGC standards so i am still a little bit confused
>> on
>>>>>> how  to
>>>>>>> create this GML application schemas so sorry if I am asking no-
>>>>>> sense...
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Javier.
>>>>>>>
>>>>>>>
>>>>>>> On 22/11/2005, at 20:29, Justin Deoliveira wrote:
>>>>>>>
>>>>>>>> Hi Javier,
>>>>>>>>
>>>>>>>> I suspect that the GML writer ignores the information that you
>>>>>> have
>>>>>>>> supplied in the schema.xml file, and generates the gml from
>> the
>>>>>>>> actual features / feature types themselves.
>>>>>>>>
>>>>>>>> Since the DescribeFeatureType logic takes place in GeoServer
>>>>>> itself,
>>>>>>>> it can be smart and delegate to the schema.xml file.  However
>>>> the
>>>>>> GML
>>>>>>>> writing logic takes place in the geotools library,  and it has
>>>> no
>>>>>>>> notion of this file.
>>>>>>>>
>>>>>>>> Can you tell us a bit more about how you are trying to
>> customize
>>>>>> your
>>>>>>>> schema. Perhaps there is another way around this problem.
>>>>>>>>
>>>>>>>> Justin
>>>>>>>>
>>>>>>>> Javier de la Torre wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>> I am starting to play with Geoserver and until now I have to
>>>> say
>>>>>> I
>>>>>>>>> am  impressed by how easy is to install and configure,
>>>>>>>>> congratulations!!
>>>>>>>>> But when trying to edit a schema.xml file to adapt the output
>>>> of
>>>>>> a
>>>>>>>>> WFS service I get into problems. In the documentation it
>> says:
>>>>>>>>> "The last file is not always present, it is the schema.xml
>>>> file.
>>>>>>>>> This  is a tricky file - if present it is used directly for a
>>>>>>>>> DescribeFeatureType response, but configuration information
>> is
>>>>>> also
>>>>>>>>> read from it. If it is absent then the DescribeFeatureType
>>>>>> response
>>>>>>>>> is automatically generated by GeoServer with the  default
>>>>>>>>> AttributeTypes of the DataStore (such as the columns of  the
>>>>>> table)."
>>>>>>>>> But if I edit manually this file Geoserver does not take care
>>>> of
>>>>>> it
>>>>>>>>> for producing the GML of the features, but it does for the
>>>>>>>>> DescribeFeatureType....
>>>>>>>>> And the Graphical interface automatically overwrite to the
>>>>>> default
>>>>>>>>> one...
>>>>>>>>> Do you know what is going on?
>>>>>>>>> Thanks in advance.
>>>>>>>>> Javier.
>>>>>>>>> -------------------------------------------------------
>>>>>>>>> This SF.Net email is sponsored by the JBoss Inc.  Get
>> Certified
>>>>>> Today
>>>>>>>>> Register for a JBoss Training Course.  Free Certification
>> Exam
>>>>>>>>> for All Training Attendees Through End of 2005. For more info
>>>>>> visit:
>>>>>>>>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
>>>>>>>>> _______________________________________________
>>>>>>>>> Geoserver-users mailing list
>>>>>>>>> Geoserver-users at lists.sourceforge.net
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Justin Deoliveira
>>>>>>>> The Open Planning Project
>>>>>>>> http://topp.openplans.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Justin Deoliveira
>>>>>> The Open Planning Project
>>>>>> http://topp.openplans.org
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------
>>>>>> This SF.Net email is sponsored by the JBoss Inc.  Get Certified
>>>> Today
>>>>>> Register for a JBoss Training Course.  Free Certification Exam
>>>>>> for All Training Attendees Through End of 2005. For more info
>>>> visit:
>>>>>> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
>>>>>> _______________________________________________
>>>>>> Geoserver-users mailing list
>>>>>> Geoserver-users at lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------------------------
>>>>> This mail sent through IMP: https://webmail.limegroup.com/
>>>>
>>>
>>>
>>>
>>>
>>> ----------------------------------------------------------
>>> This mail sent through IMP: https://webmail.limegroup.com/
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD
>> SPLUNK!
>> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> _______________________________________________
>> Geoserver-devel mailing list
>> Geoserver-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>
>
>
>
> ----------------------------------------------------------
> This mail sent through IMP: https://webmail.limegroup.com/