On Monday 17 September 2007 17:26:41 Justin Deoliveira wrote:
> >> So simpleFeature.getAttribute("name") would indeed match content created
> >> with a "gml:name" (the gml prefix internally would of been matched
> >> against a
> >> NameImpl("http://schemas.opengis.net/gml/3.2.1/gml.xsd","name";).
> >
> > Right, but if you're talking about SimpleFeature, I don't think
> > SimpleFeature could extend from gml:Feature as gml:name has multiplicity
> > 0..N, which makes it non simple by definition?
>
> Good point Gabriel, you are correct. I am in agreement with Jody on this
> one in that I think attribute names should be left unqualified, and
> mapped on the encoding side. What are your thoughts?
I would say to stay simple and consistent. I.e. no hacking at the geoserver
side to match an unqualified "name" attribute to "gml:name". Same for
location, etc.
Rationale: gml:name has its semantic, and might be different from the "name"
attribute of a single db table. If a postgis, shapefile, etc table has a name
attribute, encode it with the datastore provided namespace. This makes the
encoding more straightforward and avoids the counter-hack when one actually
don't want it to be encoded as gml:name.
If you want a field from your table to be mapped as gml:name (and actually
there's no need for the original att to be called name) you should be able of
doing that and much more, which is what the community-schema datastore is
for. Yeah I know its still in unsupported, yet I would say to keep the
encoder straight forward and avoid hacking, there's a much better solution to
map a legacy data structure to another one, legacy or not.
my 2c.-
Cheers,
Gabriel
>
> > Gabriel
> >
> >> That is:
> >>> <element name="name" type="gml:CodeType">
> >>> <annotation>
> >>> <documentation>The gml:name property provides a label or identifier
> >>> for the object,...</documentation> </annotation>
> >>> </element>
> >>
> >> Is this what you are talking about? It looks to be the one referenced in
> >> "StandardObjectProperties" ...
> >>
> >> Cheers,
> >> Jody
> >>
> >> ------------------------------------------------------------------------
> >>- This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2005.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >> _______________________________________________
> >> Geoapi-devel mailing list
> >> [EMAIL PROTECTED]
> >> https://lists.sourceforge.net/lists/listinfo/geoapi-devel
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Geotools-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
> > !DSPAM:4007,46ee418f32521015089218!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
