I send a bad explanation in the after email
i try ot get the feature whit the next request:
http://localhost:8080/geoserver/GetFeature?featureid=topp:road.1
...
http://localhost:8080/geoserver/GetFeature?featureid=road.1
and get the rigth gml documentit is a bug?
Oh, I see. Yes, that is a bug. If you call getFeature?typename=topp:road
then getFeature?featureid=topp:road should return. I thought I had fixed
that problem in some version of my fid kvp reader, but I guess I didn't.
I need to think about it for a bit, I'll come back when I find a solution.
I'm not a big fan of KVP's as they aren't super well thought out and don't
make so much sense with all the namespace requirements. I mean, if you're
using a namespace prefix then it should actually be defined somewhere in
the request. The spec comments on this for Filter, but not for the
FEATUREID kvp. The FEATUREID is especially annoying, as it assumes that
all featureIDs are oracle style, with the tablename prepended to a number,
when in fact a the gml:id does not make that requirement. But I'll work
on it and see what I can come up with.
and two another question, geoserver suport the porpertyName filter?
Yes.
and geoserver support transaction operations over shapefiles?
No, not yet. There is some good work being done in geotools which may
eventually lead to this happening, but as of now no.
William Moreno
----- Original Message -----
From: "Chris Holmes" <cholmes@anonymised.com>
To: "Bladimir Moreno" <bladiyo@anonymised.com>
Cc: <geoserver-devel@lists.sourceforge.net>
Sent: Monday, October 13, 2003 2:31 PM
Subject: Re: getfeature bug> > I discover the next possible bug in geoserver, in the getfeature
function i
> > get the gml document from the
> > http://localhost:port/geoserver/GetFeature?FeatureName=road request
> > i declare the road Feature in the namespace topp. The request wuold be
> > http://localhost:port/geoserver/GetFeature?FeatureName=topp:road ?
>
> Yeah, that's intentional. topp is the default namespace, so that if you
> don't specify a namespace it defaults to that. This was for backwards
> compatibility, as we used to not handle namespaces. But I think it's
> still kind of nice to be able to not have to specify the annoying topp:
> prefix before everything, if all your features are in the same namespace.
>
> I did change the defaultNamespace to be the first defined one if the
> 'default' attribute was not used, as the 'default' attribute wasn't
> necessarily intuitive if you only wanted to define one namespace. Users
> were defining namespaces and wondering why myns was still showing up. The
> request with the namespace of topp: still works right? If not then it's a
> bug, and I'd like to see your configuration files to try to replicate it.
>
> Chris
>
>
> >
> > William Moreno
> >
> > ----------- Mensaje Original --------------
> >
> > De: Sean Geoghegan [sean@anonymised.com]
> > Para: Chris Holmes [cholmes@anonymised.com]
> > Cc: geoserver-devel@lists.sourceforge.net
> > [geoserver-devel@lists.sourceforge.net]
> > Asunto: Re: [Geoserver-devel] Initial WMS support in CVS.
> > Fecha: 06/10/2003 19:38:26
> > Mensaje:
> >
> >
> > Hi Chris,
> >
> > I was just wondering if there is, or you have thought of a roadmap for
> > the WMS server once the integration is complete? Personally, I would
> > love to see the WMS as standards compliant as Geoserver's WFS. I could
> > probably arrange to have some effort of my own put to this task aswell,
> > since there are some WMS Features that I would like to use but aren't
> > present in many other open source offerings.
> >
> > So maybe a list of features requests and improvements should be put
> > together??
> >
> > Sean
> >
> > Chris Holmes wrote:
> >
> > >Just wanted to give everyone a heads up that my initial stab at
integrated
> > >WMS support is now in CVS.
> > >
> > >I was trying today to get it working with postgis, but am as of yet
> > >unsuccessful. I need to deal with bounding boxes, as postgis
datasources
> > >don't like giving them, and the WMS code really likes having them.
I'll
> > >probably implement getBounds for postgis _and_ figure out a way to have
> > >wms code deal with not being able to query the bounds. Either would
fix
> > >the problem but both cases seem good to solve.
> > >
> > >As for running the wms, the relevant configuration files are either
> > >integrated with geoserver or in misc/wms. For the layers that you want
> > >the wms to serve, just fill out the misc/data/FeatureTypes as you
always
> > >do, but add tags for styles:
> > ><Style id="green" filename="green.sld"/>
> > >The style filenames should be contained in misc/wms/styles/. Note that
if
> > >you have styles from gt2wms you no longer have the styles/ prefix,
> > >geoserver puts them in a slightly different location (data/styles), and
> > >resolves the rest of the location for you.
> > >
> > >The layers.xml file is no longer used, so if you have existing installs
of
> > >gt2wms you'll have to change them over to info.xml files. The
datasource
> > >params should stay pretty much the same. The easiest way to move
things
> > >over is to put the related map file from the old gt2wms maps directory
> > >into the same folder as info.xml, and use the filename parameter to
> > >specify the name of the file, and it will be resolved into the
appropriate
> > >url parameter. If you must keep it in another location then specify
the
> > >full file url, file:/home/chris/maps/trees.shp.
> > >
> > >I'll try to get a sample file that works for both into cvs pretty soon.
> > >The one I've been using is a bit large though, so I'm reluctant to put
it
> > >in. If anyone has a nice small shapefile that actually represents
> > >something real and can make a little map with the wms send it to me and
> > >I'll add it. The current shapefile is just 4 made up features.
> > >
> > >The capabilities documents are still forked, hopefully we can get some
> > >good integration on those, since so many of the elements overlap. For
now
> > >the capabilities.xml of gt2wms is just kept in misc/wms, and copied
> > >directly over.
> > >
> > >As for quering it, I've replaced the /servlet/gt2wms? prefix with
> > >/geoserver/wms?, to mirror the dispatcher's location of /geoserver/wfs?
> > >So you can ask wms?request=GetCapabilities and
> > >wfs?request=GetCapabilities, and get the respective documents (though
> > >they're still forked, so not super useful yet. Or you can do
> > >wms?request=GetMap&layer=states and
> > >wfs?request=GetFeature&typename=states. I think that's all the
> > >information you need to get started, let me know if there are more
> > >questions.
> > >
> > >As far as implementation goes, there are definitely integration
> > >improvements to be made, I've pretty much just hacked together the
current
> > >working solution, TypeInfo (the current geoserver featureType
> > >representation) objects can turn themselves into LayerEntries, and
those
> > >get added to the WMS. And the capabilities and error reporting are
still
> > >forked. So there are certainly improvements to be made on that front,
but
> > >I think we're on a good start.
> > >
> > >If anyone is interested in this stuff and can handle cvs access I'd
love
> > >feedback, on getting it working and how you might want the
configuration
> > >set up. Information on cvs access is available at
> > >http://sf.net/cvs/?group_id=25086. We'll go for an early and often
> > >release relatively soon as well, so that users can spot the new bugs
:).
> > >
> > >
> > > thanks,
> > >
> > > Chris
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This sf.net email is sponsored by:ThinkGeek
> > >Welcome to geek heaven.
> > >http://thinkgeek.com/sf
> > >_______________________________________________
> > >Geoserver-devel mailing list
> > >Geoserver-devel@lists.sourceforge.net
> > >https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > >
> > >
> >
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
> > Bladimir Moreno
> >
>
> --
>
>
--