I have added another test module for the complex stuff.
Gabriel: There is a "GetFeature" tests in the ComplexTest class. I was hoping you could run it and see what is going on.
Note: The downloaded config contains some hard coded paths you may have to change.
-Justin
I have this test passing now and geoserver is spitting out complex features.
Gabriel: I had to make a couple of changes i would like you to qa. The classes are in geotools:
ReTypeFeatureReader
ComplexAttributeImpl
look for task tags called "JD" and you find the changes, i made some notes.
-Justin
Justin Deoliveira wrote:
I have added another test module for the complex stuff.
Gabriel: There is a "GetFeature" tests in the ComplexTest class. I was hoping you could run it and see what is going on.
Note: The downloaded config contains some hard coded paths you may have to change.
-Justin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
ha! I was changing exactly the same files! just came home and was going to
commit from there, thought you were expecting that I review your config and
get features out of GetFeature.
In the way to my home, I was thinking that AsbtractDataStore should only wrap
with a RetypeFeatureReader if the feature type being processed is a
SimpleFeatureType, otherwise it is not doable?
I mean, RetypeFeatureReader.next() uses FeatureType.create(Object...), which
is a nonsense for non simple features.
Actually, I guess one of the first things we should do is to get rid of the
uses of FeatureType.create the most possible, its used quite extensively
though.
I created a unit test for FeatureTransformer, since it didn't had anyone, so
this test works over complex features, to be sure FeatureTransformer works
with complex data.
Regarding shared config, a step forward to achieve it is that I made some
modifications to how geoserver determines if a datastore parameter is
relative and then creates an absolute path with GEOSERVER_DATA_DIR.
Also modified property datastore to accept paths relative to user.dir system
property, this eliminates the hardcoded path in complexds unit tests.
The stopping issue to have a common configuration independent of the
developing environment is complex datastore's mapping files. The point is
that we can't put a relative path for the directory in the mapping file (at
least I couldn't figure out what the user.dir was when running jetty), and
also complexds can't use geoserver's data dir as base, since obviously it has
absolutely no knowledge about geoserver.
If you have any ideas regarding this it would be great.
Gabriel
On Wednesday 22 February 2006 21:45, Justin Deoliveira wrote:
I have this test passing now and geoserver is spitting out complex
features.Gabriel: I had to make a couple of changes i would like you to qa. The
classes are in geotools:ReTypeFeatureReader
ComplexAttributeImpllook for task tags called "JD" and you find the changes, i made some notes.
-Justin
Justin Deoliveira wrote:
> I have added another test module for the complex stuff.
>
> Gabriel: There is a "GetFeature" tests in the ComplexTest class. I was
> hoping you could run it and see what is going on.
>
> Note: The downloaded config contains some hard coded paths you may have
> to change.
>
> -Justin
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90
In the way to my home, I was thinking that AsbtractDataStore should only
wrap with a RetypeFeatureReader if the feature type being processed is a
SimpleFeatureType, otherwise it is not doable?
I mean, RetypeFeatureReader.next() uses FeatureType.create(Object...),
which is a nonsense for non simple features.Actually, I guess one of the first things we should do is to get rid of the
uses of FeatureType.create the most possible, its used quite extensively
though.
further explanation is that, when we were simple features, we used to treat
feature requests as if they were sql queries: tou can specify the order in
which you want the attributes to be returned, and return the subset of
attributes you like.
Now this behavior is actually wrong, FeatureTypes are often defined outside
(community schemas?), they're immutable and thus it is incorrect that the WFS
return instances with attributes in an order different than the specified in
the schema, or even redefining the schema by cutting it out.
that's why I say that AbstractDataStore should't use RetypeFeatureReader, at
least if not dealing with a simple feature type.
I will go ahead and apply that change, we could revert it if I'm wrong.
what do you think?
Gabriel.
Gabriel Roldán wrote:
ha! I was changing exactly the same files! just came home and was going to commit from there, thought you were expecting that I review your config and get features out of GetFeature.
In the way to my home, I was thinking that AsbtractDataStore should only wrap with a RetypeFeatureReader if the feature type being processed is a SimpleFeatureType, otherwise it is not doable?
I mean, RetypeFeatureReader.next() uses FeatureType.create(Object...), which is a nonsense for non simple features.Actually, I guess one of the first things we should do is to get rid of the uses of FeatureType.create the most possible, its used quite extensively though.
Yeah this is a good idea. The method has been deprecated for sime time anyhow.
I created a unit test for FeatureTransformer, since it didn't had anyone, so this test works over complex features, to be sure FeatureTransformer works with complex data.
Regarding shared config, a step forward to achieve it is that I made some modifications to how geoserver determines if a datastore parameter is relative and then creates an absolute path with GEOSERVER_DATA_DIR. Also modified property datastore to accept paths relative to user.dir system property, this eliminates the hardcoded path in complexds unit tests.
The stopping issue to have a common configuration independent of the developing environment is complex datastore's mapping files. The point is that we can't put a relative path for the directory in the mapping file (at least I couldn't figure out what the user.dir was when running jetty), and also complexds can't use geoserver's data dir as base, since obviously it has absolutely no knowledge about geoserver.
If you have any ideas regarding this it would be great.
I thought about this one for a little while. Cant really think of a transparent way to handle this easily. There needs to be a level of indirection between the geoserver app and the underlying datastore layer. ie. a catalog. Oddly enough some poor soul just ported the udig catalog into geotools :). However it will be a significant amount of work to get it in.
One thing that is for sure is that the hack geoserver uses is very ugly. I saw from the commit logs that you made it a bit nicer.
Gabriel
On Wednesday 22 February 2006 21:45, Justin Deoliveira wrote:
I have this test passing now and geoserver is spitting out complex
features.Gabriel: I had to make a couple of changes i would like you to qa. The
classes are in geotools:ReTypeFeatureReader
ComplexAttributeImpllook for task tags called "JD" and you find the changes, i made some notes.
-Justin
Justin Deoliveira wrote:
I have added another test module for the complex stuff.
Gabriel: There is a "GetFeature" tests in the ComplexTest class. I was
hoping you could run it and see what is going on.Note: The downloaded config contains some hard coded paths you may have
to change.-Justin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Gabriel Roldán wrote:
In the way to my home, I was thinking that AsbtractDataStore should only
wrap with a RetypeFeatureReader if the feature type being processed is a
SimpleFeatureType, otherwise it is not doable?
I mean, RetypeFeatureReader.next() uses FeatureType.create(Object...),
which is a nonsense for non simple features.Actually, I guess one of the first things we should do is to get rid of the
uses of FeatureType.create the most possible, its used quite extensively
though.further explanation is that, when we were simple features, we used to treat feature requests as if they were sql queries: tou can specify the order in which you want the attributes to be returned, and return the subset of attributes you like.
Now this behavior is actually wrong, FeatureTypes are often defined outside (community schemas?), they're immutable and thus it is incorrect that the WFS return instances with attributes in an order different than the specified in the schema, or even redefining the schema by cutting it out.
that's why I say that AbstractDataStore should't use RetypeFeatureReader, at least if not dealing with a simple feature type. I will go ahead and apply that change, we could revert it if I'm wrong.
what do you think?
I think I follow. The subsetting / ordering is already done in the complex type definition so what you ask for is what you get. So if someone wants to customize a complex (ie reorder or subset) type a new type needs to be defined?
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Gabriel Roldán wrote:
ha! I was changing exactly the same files! just came home and was going to commit from there, thought you were expecting that I review your config and get features out of GetFeature.
In the way to my home, I was thinking that AsbtractDataStore should only wrap with a RetypeFeatureReader if the feature type being processed is a SimpleFeatureType, otherwise it is not doable?
I mean, RetypeFeatureReader.next() uses FeatureType.create(Object...), which is a nonsense for non simple features.Actually, I guess one of the first things we should do is to get rid of the uses of FeatureType.create the most possible, its used quite extensively though.
I tried one already and had to give up (the type system was not sufficient). If you can please review the FeatureFactory
interface we can give it a go.
Jody
Justin Deoliveira wrote:
Gabriel Roldán wrote:
In the way to my home, I was thinking that AsbtractDataStore should only
wrap with a RetypeFeatureReader if the feature type being processed is a
SimpleFeatureType, otherwise it is not doable?
I mean, RetypeFeatureReader.next() uses FeatureType.create(Object...),
which is a nonsense for non simple features.Actually, I guess one of the first things we should do is to get rid of the
uses of FeatureType.create the most possible, its used quite extensively
though.further explanation is that, when we were simple features, we used to treat feature requests as if they were sql queries: tou can specify the order in which you want the attributes to be returned, and return the subset of attributes you like.
Now this behavior is actually wrong, FeatureTypes are often defined outside (community schemas?), they're immutable and thus it is incorrect that the WFS return instances with attributes in an order different than the specified in the schema, or even redefining the schema by cutting it out.
that's why I say that AbstractDataStore should't use RetypeFeatureReader, at least if not dealing with a simple feature type. I will go ahead and apply that change, we could revert it if I'm wrong.
what do you think?
I think I follow. The subsetting / ordering is already done in the complex type definition so what you ask for is what you get. So if someone wants to customize a complex (ie reorder or subset) type a new type needs to be defined?
Not so much customization, this is for when we perform a Query and only ask for two of the five attributes.
With simple features the only way to do this was w/ the associated FeatureType. To describe attributes, we had to "fake" a new FeatureType each time - it was horrible.
Now that each feature has real attributes we can manage along correctly.
Jody