Hi Ivan,
(from the other side of the country!)
I've been monitoring Geoserver progress for some time and its getting to the point now where it is a suitable platform to build an interoperable gazetteer. The OGC Gazetteer spec (discussion paper) is an implementation of a formal gazetter concept (ISO 19112) which is important, as it provides for a basis of the semantics so that two gazetteer services can be interoperable, and also provides a framework for the business rules about how the gazetteer is maintained and advertised.
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.
At this point I would like to thank the Australian Antarctic Division, also geoserver users now I believe, for support in the testing and proving and writing up of the OGC draft spec. I have been waiting (a long time!) for a resolution of official ISO schema repositories before submitting the spec for adoption.
BTW We have such a generic client... but have been waiting a long time for decent infrastructure services to evolve! Right now its more important to avoid a whole bunch of ad-hoc gazetteer implementations, and its possible we can assist in interoperability testing against the spec. Logically we would also include gazetteer conformance tests into the OGC CITE testing framework, but thats another order of magnitude of resources required.
Regards
Rob Atkinson
Social Change Online
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 GeoserverHi 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.htmland found a mention of gazetteer in geotools/geoserver(?) at:
http://sourceforge.net/mailarchive/message.php?msg_id=3D7115897the ogc spec for gaz is at:
http://www.opengis.org/docs/02-076r3.pdfHas 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
=
=20Well, I just committed a refactoring of FeatureTypeResponse to deal wit=
h a
new output format: GML2.gzto 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 GMLIMO 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.htmlSean
-----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 GMLRegarding 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-develEnd of Geoserver-devel Digest