RE: [Geoserver-devel] Re: Geoserver-devel digest, Vol 1 #260 - 1msg

At the basic level it doesn't imply any bloat at all - if the gazetteer schema simply implements gazetteer objects as a feature-type. Thus *any* WFS software that supports an externally defined feature model (i.e. a GML application schema in which the objects of interest have content models derived from gml:AbstractFeatureType) can be used for a gazetteer server.

But I know Rob also has some other issues that he believe flow on in order to make it *useful* - and perhaps those would lead to bloat.

Simon Cox

-----Original Message-----
From: cholmes@anonymised.com [mailto:cholmes@anonymised.com]
Sent: Thursday, 11 March 2004 3:56 PM
To: Rob Atkinson
Cc: geoserver-devel@lists.sourceforge.net;
Ivan.Price@anonymised.com; Lee
Belbin; Cox, Simon (E&M, Kensington)
Subject: Re: [Geoserver-devel] Re: Geoserver-devel digest,
Vol 1 #260 -
1msg

> We have a Java based implementation of the full gazetteer -
including
>
> hierarchical searches and result sets that we would like to open
> source
> by rolling into the geoserver code base now its is ready. This would
>
> require a little bit of sponsorship to make possible, but would
> address
> the looming prospect of a whole range of ad-hoc efforts that wont
> actually interoperate.
That would be great. Would make a nice GeoServer 1.3. I think
sponsership would definitely be in order, as putting gazetteer would
require some more refactoring. I'm currently getting a bit worried
about bloat - people who just want a nice simple wfs having
to also get
a wms, catalog, ui interface and gazetteer. I'd like to see
something
like plug-ins into a general framework, where you could choose which
components you wanted. A concept similar to the datastores
api, where
you can just include which ones you want, and easily plug in
new ones,
but extending to services. Granted I haven't thought this through
_at_all_, and may be technically super hard and not worth the
effort.
At the very least though the code base needs to be more flexible, so
that rolling a wfs only would not be too hard, perhaps
different build
targets could create different services, with their code and the
appropriate jars.

Looks like it's time for me to download the gazetteer spec, as it's
something I've really never looked at. I'm excited about the
possibilities though.

Chris

>
> >
> >Today's Topics:
> >
> > 1. Gazetteer profile of WFS using Geoserver
> (Ivan.Price@anonymised.com)
> >
> >--__--__--
> >
> >Message: 1
> >To: geoserver-devel@lists.sourceforge.net
> >From: Ivan.Price@anonymised.com
> >Date: Thu, 11 Mar 2004 11:57:55 +0800
> >Subject: [Geoserver-devel] Gazetteer profile of WFS using Geoserver
> >
> >
> >Hi there,
> >
> >I'm interested in implementing an ogc compatiable gazetteer,
> eventually=
> >
> >doubling as the authoritive list of place names in western
> australia,
> >(geonoma).
> >
> >Has any work been done setting up the feature types / schemeas
> required=
> > to
> >use geoserver as a gazetteer ?
> >
> >i had a look at:
> >http://ogc.compusult.nf.ca/OGC/gaz_get_search.html
> >
> >and found a mention of gazetteer in geotools/geoserver(?) at:
> >http://sourceforge.net/mailarchive/message.php?msg_id=3D7115897
> >
> >the ogc spec for gaz is at:
> >http://www.opengis.org/docs/02-076r3.pdf
> >
> >Has anyone else done any work in this area ? It seems there are a
> few c=
> >ases
> >where people use their WFS as a gazetteer using their own methods
> and
> >client, i.e. get feature requests on a point layer they know the
> name o=
> >f
> >before hand, but there is a lack of a generic client you can point
> at a=
> > ogc
> >gazetteer to extract info from as there are for wfs/wms etc.
> >
> >also, congrats on the gzipped GML 2 days after it's raised on the
> maili=
> >ng
> >list.. awesome.
> >
> >-ivan
> >
> >Ivan Price
> >Government Information Solutions
> >Department of Land Information
> >Western Australia
> >Ivan.Price@anonymised.com
> >+61 08 9273 7520
> >
> >
> >
> >
> >
         
> =
> > =20
> > Gabriel Rold=E1n
         
> =
> > =20
> > <gabriel.roldan@anonymised.com To:
"Geoghegan,
> Se=
> >an" <Sean.Geoghegan@anonymised.com>, =20
> > onica.net> Chris Holmes
> <cholmes@=
> >openplans.org>, Paul Ramsey =20
> >
> <pramsey@anonymised.com=
> >et> =20
> > 11/03/2004 08:01 cc:
> geoserver-deve=
> >l@lists.sourceforge.net =20
> > Subject: Re:
> [Geos=
> >erver-devel] GZ GML =20
> >
         
> =
> > =20
> >
> >
> >
> >Well, I just committed a refactoring of FeatureTypeResponse to deal
> wit=
> >h a
> >new output format: GML2.gz
> >
> >to do that, I needed to separate the execution of the query from
> the
> >response preparation in execute().
> >The apporach was to leave FeatureResponse deal with the execution
> and m=
> >ake
> >delegates for encoding to
> >the desired output format.
> >Also added getContentEncoding to Response interface, wich returns
> null =
> >or
> >the content encoding if there are any. GML2FeatureResponseDelegate
> retu=
> >rns
> >"gzip" if outputformat was "GML2.gz". This delegate deals with both
> GML=
> >2
> >and
> >GML2.gz formats, but the API now allows to add new encoders for
> other
> >output
> >formats by just adding a new encoder (implementation of
> >FeatureResponseDelegate) in FeatureResponseDelegateFactory.
> >
> >I have tested it almost extensively and I'm getting the same result
> as
> >before the change.
> >
> >Any feedback will be appreciated.
> >
> >best regards,
> >
> >gabriel
> >
> >----- Original Message -----
> >From: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>
> >To: "'Chris Holmes'" <cholmes@anonymised.com>; "Paul Ramsey"
> ><pramsey@anonymised.com>
> >Cc: <geoserver-devel@lists.sourceforge.net>
> >Sent: Wednesday, March 10, 2004 4:25 AM
> >Subject: RE: [Geoserver-devel] GZ GML
> >
> >
> >
> >
> >>IMO stuff like Gzip should be handled at either the HTTP server
> level=
> >>
> >>
> >, as
> >Paul mentioned, or by using Servlet Filters. This means Geoserver
> does=
> > not
> >have to handle it directly.
> >
> >
> >>There is a good article on Servlet filters for content compression
> at=
> >>
> >>
> >
> >http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html
> >
> >
> >>Sean
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: Chris Holmes [mailto:cholmes@anonymised.com]
> >>>Sent: Wednesday, 10 March 2004 10:43 AM
> >>>To: Paul Ramsey
> >>>Cc: geoserver-devel@lists.sourceforge.net
> >>>Subject: Re: [Geoserver-devel] GZ GML
> >>>
> >>>
> >>>
> >>>>Regarding gzipped GML, should GeoServer do this at all? This is
> a=
> >>>>
> >>>>
> >
> >
> >
> >>>>protocol level thing, the client requests compression if
> >>>>
> >>>>
> >>>possible and
> >>>
> >>>
> >>>>the server compresses if able. You could probably make GeoServer
> =
> >>>>
> >>>>
> >do
> >
> >
> >>>>compression just be running it behind a web server that
> supported=
> >>>>
> >>>>
> >
> >
> >
> >>>>compression, like Apache with mod_deflate enabled. Why add any
> >>>>infrastructure at all to GeoServer, it is an HTTP thing.
> >>>>
> >>>>
> >>>Well, I think GeoServer should definitely send gzipped gml if
> >>>the client specifically requests it (in the getFeature
> >>>request), as this is completely in the scope of the spec, to
> >>>request different formats. This way clients who don't know
> >>>how to ask for the gzipped stuff in the http header can also get
> it=
> >>>
> >>>
> >.
> >
> >
> >>>As for doing it automatically, I'm a bit ambivalent. On the
> >>>one hand I do sorta agree that it's a lower level compression
> >>>that geoserver shouldn't do. But on the other hand geoserver
> >>>is a server, and one of the main design goals is to make it
> >>>really easy to set up while still being very powerful. I
> >>>imagine that a number of users who have some data to share
> >>>aren't sys admins who are super experienced at compiling
> >>>apache with mod_deflate, let alone setting up apache with a
> >>>connector to a servlet container (something I've done once or
> >>>twice and definitely found it to be a bitch). Most all
> >>>installs of geoserver I've seen are run directly from the
> >>>servlet container, so from that perspective I think it makes
> >>>sense to do it for them if we can, as I don't believe (I
> >>>could be wrong here) that tomcat or resin or any of them do
> >>>that sort of compression in their built in web servers. So
> >>>yeah, the one thing I'm going to insist with Gabriel rolling
> >>>it in is that it's absolutely seamless. Gabriel, could you
> >>>start it on a branch or give it a config option similar to
> >>>the SPEED strategy, so we can test it out before it just
> >>>shows up in geoserver code? I think it should maybe wait
> >>>until 1.2.1, at least as a default. Make the option
> >>>available in 1.2.0 so we can all sanity check it if we want
> >>>to. And even in 1.2.1 I think we should put an option in the
> >>>services.xml file (and in the ui) for users to turn it on or off.
> >>>
> >>>Chris
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>P.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>--
> >>>
> >>>
> >>>
> >>>-------------------------------------------------------
> >>>This SF.Net email is sponsored by: IBM Linux Tutorials Free
> >>>Linux tutorial presented by Daniel Robbins, President and CEO
> >>>of GenToo technologies. Learn everything from fundamentals to
> >>>system
> >>>administration.http://ads.osdn.com/?
ad_id=3D1470&alloc_id=3D3638&op=
> >>>
> >>>
> >=3Dclick
> >
> >
> >>>_______________________________________________
> >>>Geoserver-devel mailing list
> >>>Geoserver-devel@lists.sourceforge.net
> >>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >>>
> >>>
> >>>
> >>-------------------------------------------------------
> >>This SF.Net email is sponsored by: IBM Linux Tutorials
> >>Free Linux tutorial presented by Daniel Robbins, President and CEO
> of=
> >>
> >>
> >
> >
> >
> >>GenToo technologies. Learn everything from fundamentals to system
> >>administration.http://ads.osdn.com/?
ad_id=3D1470&alloc_id=3D3638&op=3D=
> >>
> >>
> >click
> >
> >
> >>_______________________________________________
> >>Geoserver-devel mailing list
> >>Geoserver-devel@lists.sourceforge.net
> >>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email is sponsored by: IBM Linux Tutorials
> >Free Linux tutorial presented by Daniel Robbins, President and CEO
> of
> >GenToo technologies. Learn everything from fundamentals to system
> >administration.http://ads.osdn.com/?
ad_id=3D1470&alloc_id=3D3638&op=3Dc=
> >lick
> >_______________________________________________
> >Geoserver-devel mailing list
> >Geoserver-devel@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
> >
> >
> > **
> >Responsibility for the administration and management of Crown land
> has
> >transferred from the Department of Land Information (DLI), formerly
> DOL=
> >A,
> >to the Department for Planning and Infrastructure (DPI) as of July
> 1, 2=
> >003.
> >
> >Although continuing to operate from DLI's Midland office, Land
> >Administration Services and associated support staff (who will be
> known=
> > as
> >Land Asset Management Services) can now be contacted on (08) 9347
> 5000 =
> >and
> >post: PO Box 1575 Midland, WA, 6936.
> >
> > **
> >
> >This e-mail and any files transmitted with it are intended only for
> the=
> > use
> >of the addressee(s). It may contain information that is
> confidential a=
> >nd
> >privileged. If you are not an intended recipient, any use,
> interferenc=
> >e
> >with, disclosure, distribution or copying of this material is
> unauthori=
> >sed
> >and prohibited. If you receive this in error, please notify the
> author =
> >by
> >return e-mail or telephone +61-8-9273 7533. Information in this
> messag=
> >e
> >not relating to the official business of DLI shall be understood as
> nei=
> >ther
> >given nor endorsed by it. While every care is taken, it is
> recommended=
> >
> >that you scan any attachments for viruses. DLI liability is limited
> to
> >re-supplying affected attachments.=
> >
> >
> >
> >
> >
> >--__--__--
> >
> >_______________________________________________
> >Geoserver-devel mailing list
> >Geoserver-devel@lists.sourceforge.net
> >https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> >
> >
> >End of Geoserver-devel Digest
> >
> >
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO
> of
> GenToo technologies. Learn everything from fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

At the basic level it doesn't imply any bloat at all - if the gazetteer
schema simply implements gazetteer objects as a feature-type. Thus *any*
WFS software that supports an externally defined feature model (i.e. a
GML application schema in which the objects of interest have content
models derived from gml:AbstractFeatureType) can be used for a gazetteer
server.

Uh yeah...just showing of my copious knowledge of gazetteers :wink: (I'm
downloading the ogc spec as we speak). Is the iso one available
somewhere? Do I have to be a member of some organization? Could someone
send me a link or the doc itself?

Chris

> -----Original Message-----
> From: cholmes@anonymised.com [mailto:cholmes@anonymised.com]
> Sent: Thursday, 11 March 2004 3:56 PM
> To: Rob Atkinson
> Cc: geoserver-devel@lists.sourceforge.net;
> Ivan.Price@anonymised.com; Lee
> Belbin; Cox, Simon (E&M, Kensington)
> Subject: Re: [Geoserver-devel] Re: Geoserver-devel digest,
> Vol 1 #260 -
> 1msg
>
>
>
> > We have a Java based implementation of the full gazetteer -
> including
> >
> > hierarchical searches and result sets that we would like to open
> > source
> > by rolling into the geoserver code base now its is ready. This would
> >
> > require a little bit of sponsorship to make possible, but would
> > address
> > the looming prospect of a whole range of ad-hoc efforts that wont
> > actually interoperate.
> That would be great. Would make a nice GeoServer 1.3. I think
> sponsership would definitely be in order, as putting gazetteer would
> require some more refactoring. I'm currently getting a bit worried
> about bloat - people who just want a nice simple wfs having
> to also get
> a wms, catalog, ui interface and gazetteer. I'd like to see
> something
> like plug-ins into a general framework, where you could choose which
> components you wanted. A concept similar to the datastores
> api, where
> you can just include which ones you want, and easily plug in
> new ones,
> but extending to services. Granted I haven't thought this through
> _at_all_, and may be technically super hard and not worth the
> effort.
> At the very least though the code base needs to be more flexible, so
> that rolling a wfs only would not be too hard, perhaps
> different build
> targets could create different services, with their code and the
> appropriate jars.
>
> Looks like it's time for me to download the gazetteer spec, as it's
> something I've really never looked at. I'm excited about the
> possibilities though.
>
> Chris
>
> >
> > >
> > >Today's Topics:
> > >
> > > 1. Gazetteer profile of WFS using Geoserver
> > (Ivan.Price@anonymised.com)
> > >
> > >--__--__--
> > >
> > >Message: 1
> > >To: geoserver-devel@lists.sourceforge.net
> > >From: Ivan.Price@anonymised.com
> > >Date: Thu, 11 Mar 2004 11:57:55 +0800
> > >Subject: [Geoserver-devel] Gazetteer profile of WFS using Geoserver
> > >
> > >
> > >Hi there,
> > >
> > >I'm interested in implementing an ogc compatiable gazetteer,
> > eventually=
> > >
> > >doubling as the authoritive list of place names in western
> > australia,
> > >(geonoma).
> > >
> > >Has any work been done setting up the feature types / schemeas
> > required=
> > > to
> > >use geoserver as a gazetteer ?
> > >
> > >i had a look at:
> > >http://ogc.compusult.nf.ca/OGC/gaz_get_search.html
> > >
> > >and found a mention of gazetteer in geotools/geoserver(?) at:
> > >http://sourceforge.net/mailarchive/message.php?msg_id=3D7115897
> > >
> > >the ogc spec for gaz is at:
> > >http://www.opengis.org/docs/02-076r3.pdf
> > >
> > >Has anyone else done any work in this area ? It seems there are a
> > few c=
> > >ases
> > >where people use their WFS as a gazetteer using their own methods
> > and
> > >client, i.e. get feature requests on a point layer they know the
> > name o=
> > >f
> > >before hand, but there is a lack of a generic client you can point
> > at a=
> > > ogc
> > >gazetteer to extract info from as there are for wfs/wms etc.
> > >
> > >also, congrats on the gzipped GML 2 days after it's raised on the
> > maili=
> > >ng
> > >list.. awesome.
> > >
> > >-ivan
> > >
> > >Ivan Price
> > >Government Information Solutions
> > >Department of Land Information
> > >Western Australia
> > >Ivan.Price@anonymised.com
> > >+61 08 9273 7520
> > >
> > >
> > >
> > >
> > >
>
> > =
> > > =20
> > > Gabriel Rold=E1n
>
> > =
> > > =20
> > > <gabriel.roldan@anonymised.com To:
> "Geoghegan,
> > Se=
> > >an" <Sean.Geoghegan@anonymised.com>, =20
> > > onica.net> Chris Holmes
> > <cholmes@=
> > >openplans.org>, Paul Ramsey =20
> > >
> > <pramsey@anonymised.com=
> > >et> =20
> > > 11/03/2004 08:01 cc:
> > geoserver-deve=
> > >l@lists.sourceforge.net =20
> > > Subject: Re:
> > [Geos=
> > >erver-devel] GZ GML =20
> > >
>
> > =
> > > =20
> > >
> > >
> > >
> > >Well, I just committed a refactoring of FeatureTypeResponse to deal
> > wit=
> > >h a
> > >new output format: GML2.gz
> > >
> > >to do that, I needed to separate the execution of the query from
> > the
> > >response preparation in execute().
> > >The apporach was to leave FeatureResponse deal with the execution
> > and m=
> > >ake
> > >delegates for encoding to
> > >the desired output format.
> > >Also added getContentEncoding to Response interface, wich returns
> > null =
> > >or
> > >the content encoding if there are any. GML2FeatureResponseDelegate
> > retu=
> > >rns
> > >"gzip" if outputformat was "GML2.gz". This delegate deals with both
> > GML=
> > >2
> > >and
> > >GML2.gz formats, but the API now allows to add new encoders for
> > other
> > >output
> > >formats by just adding a new encoder (implementation of
> > >FeatureResponseDelegate) in FeatureResponseDelegateFactory.
> > >
> > >I have tested it almost extensively and I'm getting the same result
> > as
> > >before the change.
> > >
> > >Any feedback will be appreciated.
> > >
> > >best regards,
> > >
> > >gabriel
> > >
> > >----- Original Message -----
> > >From: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>
> > >To: "'Chris Holmes'" <cholmes@anonymised.com>; "Paul Ramsey"
> > ><pramsey@anonymised.com>
> > >Cc: <geoserver-devel@lists.sourceforge.net>
> > >Sent: Wednesday, March 10, 2004 4:25 AM
> > >Subject: RE: [Geoserver-devel] GZ GML
> > >
> > >
> > >
> > >
> > >>IMO stuff like Gzip should be handled at either the HTTP server
> > level=
> > >>
> > >>
> > >, as
> > >Paul mentioned, or by using Servlet Filters. This means Geoserver
> > does=
> > > not
> > >have to handle it directly.
> > >
> > >
> > >>There is a good article on Servlet filters for content compression
> > at=
> > >>
> > >>
> > >
> > >http://www.onjava.com/pub/a/onjava/2003/11/19/filters.html
> > >
> > >
> > >>Sean
> > >>
> > >>
> > >>
> > >>>-----Original Message-----
> > >>>From: Chris Holmes [mailto:cholmes@anonymised.com]
> > >>>Sent: Wednesday, 10 March 2004 10:43 AM
> > >>>To: Paul Ramsey
> > >>>Cc: geoserver-devel@lists.sourceforge.net
> > >>>Subject: Re: [Geoserver-devel] GZ GML
> > >>>
> > >>>
> > >>>
> > >>>>Regarding gzipped GML, should GeoServer do this at all? This is
> > a=
> > >>>>
> > >>>>
> > >
> > >
> > >
> > >>>>protocol level thing, the client requests compression if
> > >>>>
> > >>>>
> > >>>possible and
> > >>>
> > >>>
> > >>>>the server compresses if able. You could probably make GeoServer
> > =
> > >>>>
> > >>>>
> > >do
> > >
> > >
> > >>>>compression just be running it behind a web server that
> > supported=
> > >>>>
> > >>>>
> > >
> > >
> > >
> > >>>>compression, like Apache with mod_deflate enabled. Why add any
> > >>>>infrastructure at all to GeoServer, it is an HTTP thing.
> > >>>>
> > >>>>
> > >>>Well, I think GeoServer should definitely send gzipped gml if
> > >>>the client specifically requests it (in the getFeature
> > >>>request), as this is completely in the scope of the spec, to
> > >>>request different formats. This way clients who don't know
> > >>>how to ask for the gzipped stuff in the http header can also get
> > it=
> > >>>
> > >>>
> > >.
> > >
> > >
> > >>>As for doing it automatically, I'm a bit ambivalent. On the
> > >>>one hand I do sorta agree that it's a lower level compression
> > >>>that geoserver shouldn't do. But on the other hand geoserver
> > >>>is a server, and one of the main design goals is to make it
> > >>>really easy to set up while still being very powerful. I
> > >>>imagine that a number of users who have some data to share
> > >>>aren't sys admins who are super experienced at compiling
> > >>>apache with mod_deflate, let alone setting up apache with a
> > >>>connector to a servlet container (something I've done once or
> > >>>twice and definitely found it to be a bitch). Most all
> > >>>installs of geoserver I've seen are run directly from the
> > >>>servlet container, so from that perspective I think it makes
> > >>>sense to do it for them if we can, as I don't believe (I
> > >>>could be wrong here) that tomcat or resin or any of them do
> > >>>that sort of compression in their built in web servers. So
> > >>>yeah, the one thing I'm going to insist with Gabriel rolling
> > >>>it in is that it's absolutely seamless. Gabriel, could you
> > >>>start it on a branch or give it a config option similar to
> > >>>the SPEED strategy, so we can test it out before it just
> > >>>shows up in geoserver code? I think it should maybe wait
> > >>>until 1.2.1, at least as a default. Make the option
> > >>>available in 1.2.0 so we can all sanity check it if we want
> > >>>to. And even in 1.2.1 I think we should put an option in the
> > >>>services.xml file (and in the ui) for users to turn it on or off.
> > >>>
> > >>>Chris
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>P.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>--
> > >>>
> > >>>
> > >>>
> > >>>-------------------------------------------------------
> > >>>This SF.Net email is sponsored by: IBM Linux Tutorials Free
> > >>>Linux tutorial presented by Daniel Robbins, President and CEO
> > >>>of GenToo technologies. Learn everything from fundamentals to
> > >>>system
> > >>>administration.http://ads.osdn.com/?
> ad_id=3D1470&alloc_id=3D3638&op=
> > >>>
> > >>>
> > >=3Dclick
> > >
> > >
> > >>>_______________________________________________
> > >>>Geoserver-devel mailing list
> > >>>Geoserver-devel@lists.sourceforge.net
> > >>>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >>>
> > >>>
> > >>>
> > >>-------------------------------------------------------
> > >>This SF.Net email is sponsored by: IBM Linux Tutorials
> > >>Free Linux tutorial presented by Daniel Robbins, President and CEO
> > of=
> > >>
> > >>
> > >
> > >
> > >
> > >>GenToo technologies. Learn everything from fundamentals to system
> > >>administration.http://ads.osdn.com/?
> ad_id=3D1470&alloc_id=3D3638&op=3D=
> > >>
> > >>
> > >click
> > >
> > >
> > >>_______________________________________________
> > >>Geoserver-devel mailing list
> > >>Geoserver-devel@lists.sourceforge.net
> > >>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >>
> > >>
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by: IBM Linux Tutorials
> > >Free Linux tutorial presented by Daniel Robbins, President and CEO
> > of
> > >GenToo technologies. Learn everything from fundamentals to system
> > >administration.http://ads.osdn.com/?
> ad_id=3D1470&alloc_id=3D3638&op=3Dc=
> > >lick
> > >_______________________________________________
> > >Geoserver-devel mailing list
> > >Geoserver-devel@lists.sourceforge.net
> > >https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> > >
> > >
> > > **
> > >Responsibility for the administration and management of Crown land
> > has
> > >transferred from the Department of Land Information (DLI), formerly
> > DOL=
> > >A,
> > >to the Department for Planning and Infrastructure (DPI) as of July
> > 1, 2=
> > >003.
> > >
> > >Although continuing to operate from DLI's Midland office, Land
> > >Administration Services and associated support staff (who will be
> > known=
> > > as
> > >Land Asset Management Services) can now be contacted on (08) 9347
> > 5000 =
> > >and
> > >post: PO Box 1575 Midland, WA, 6936.
> > >
> > > **
> > >
> > >This e-mail and any files transmitted with it are intended only for
> > the=
> > > use
> > >of the addressee(s). It may contain information that is
> > confidential a=
> > >nd
> > >privileged. If you are not an intended recipient, any use,
> > interferenc=
> > >e
> > >with, disclosure, distribution or copying of this material is
> > unauthori=
> > >sed
> > >and prohibited. If you receive this in error, please notify the
> > author =
> > >by
> > >return e-mail or telephone +61-8-9273 7533. Information in this
> > messag=
> > >e
> > >not relating to the official business of DLI shall be understood as
> > nei=
> > >ther
> > >given nor endorsed by it. While every care is taken, it is
> > recommended=
> > >
> > >that you scan any attachments for viruses. DLI liability is limited
> > to
> > >re-supplying affected attachments.=
> > >
> > >
> > >
> > >
> > >
> > >--__--__--
> > >
> > >_______________________________________________
> > >Geoserver-devel mailing list
> > >Geoserver-devel@lists.sourceforge.net
> > >https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> > >
> > >End of Geoserver-devel Digest
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO
> > of
> > GenToo technologies. Learn everything from fundamentals to system
> >
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > ________________________

--