[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=7115897

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 cases
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 of
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 mailing
list.. awesome.

-ivan

Ivan Price
Government Information Solutions
Department of Land Information
Western Australia
Ivan.Price@anonymised.com
+61 08 9273 7520

                    Gabriel Roldán
                    <gabriel.roldan@anonymised.com To: "Geoghegan, Sean" <Sean.Geoghegan@anonymised.com>,
                    onica.net> Chris Holmes <cholmes@anonymised.com3...>, Paul Ramsey
                                                 <pramsey@anonymised.com>
                    11/03/2004 08:01 cc: geoserver-devel@anonymised.comsts.sourceforge.net
                                                 Subject: Re: [Geoserver-devel] GZ GML
                                                                                                                   
Well, I just committed a refactoring of FeatureTypeResponse to deal with 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 make
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 returns
"gzip" if outputformat was "GML2.gz". This delegate deals with both GML2
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=1470&alloc_id=3638&op=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=1470&alloc_id=3638&op=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=1470&alloc_id=3638&op=click
_______________________________________________
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 DOLA,
to the Department for Planning and Infrastructure (DPI) as of July 1, 2003.

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 and
privileged. If you are not an intended recipient, any use, interference
with, disclosure, distribution or copying of this material is unauthorised
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 message
not relating to the official business of DLI shall be understood as neither
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.