In this old JIRA task, the "Properties" data store was removed:
https://fisheye.codehaus.org/browse/GEOS-2590
Now there is a data store in 2.0-RC1 called "Properties" with the description:
"Allows access to Java Property files containing Feature information"
Is this a different "Properties" than that discussed on the old JIRA task above? I don't know anything about this type of data store, and I'm trying to fill out the "Working With Data" section of the docs, so any information would be appreciated.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
Mike Pumphrey ha scritto:
In this old JIRA task, the "Properties" data store was removed:
https://fisheye.codehaus.org/browse/GEOS-2590
Now there is a data store in 2.0-RC1 called "Properties" with the
description:
"Allows access to Java Property files containing Feature information"
Is this a different "Properties" than that discussed on the old JIRA
task above? I don't know anything about this type of data store, and
I'm trying to fill out the "Working With Data" section of the docs,
so any information would be appreciated.
Nope, it's the same datastore that somehow popped back into
the dependencis.
I must say I'm not too surprised... all of our vector data related
tests use property files, if a developer needs to check something
"live" he'll add back the dependency.
Say the next day he forgets about it, commits the pom.xml file,
and we're back to square one.
Maybe we should add custom code so that the property data store
is available in the UI only if the UI is in development mode
or something?
Otherwise we need to keep attention up and remove it any time
it gets back in the distribution
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hi Mike,
it is the same properties data store, but we don't ship with it because it's not for production usage. We only use it for test data, so there's no need to document it on the user docs.
Does that answer your question?
Cheers,
Gabriel
Mike Pumphrey wrote:
In this old JIRA task, the "Properties" data store was removed:
https://fisheye.codehaus.org/browse/GEOS-2590
Now there is a data store in 2.0-RC1 called "Properties" with the description:
"Allows access to Java Property files containing Feature information"
Is this a different "Properties" than that discussed on the old JIRA task above? I don't know anything about this type of data store, and I'm trying to fill out the "Working With Data" section of the docs, so any information would be appreciated.
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Maybe we should add custom code so that the property data store
is available in the UI only if the UI is in development mode
or something?
I like this idea. Shall I JIRA?
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
Andrea Aime wrote:
Mike Pumphrey ha scritto:
In this old JIRA task, the "Properties" data store was removed:
https://fisheye.codehaus.org/browse/GEOS-2590
Now there is a data store in 2.0-RC1 called "Properties" with the
description:
"Allows access to Java Property files containing Feature information"
Is this a different "Properties" than that discussed on the old JIRA
task above? I don't know anything about this type of data store, and
I'm trying to fill out the "Working With Data" section of the docs,
so any information would be appreciated.
Nope, it's the same datastore that somehow popped back into
the dependencis.
I must say I'm not too surprised... all of our vector data related
tests use property files, if a developer needs to check something
"live" he'll add back the dependency.
Say the next day he forgets about it, commits the pom.xml file,
and we're back to square one.
Maybe we should add custom code so that the property data store
is available in the UI only if the UI is in development mode
or something?
Otherwise we need to keep attention up and remove it any time
it gets back in the distribution
Cheers
Andrea
Mike Pumphrey ha scritto:
Maybe we should add custom code so that the property data store
is available in the UI only if the UI is in development mode
or something?
I like this idea. Shall I JIRA?
The downside of this is that there won't be any chance
of using the property data store in a released GeoServer
(unless someone fiddles with the GS config manually).
Not sure... would like to hear the opinion of other
developers on this one.
But you can open the jira... worst case we'll solve
it as won't fix, so no big deal
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I think its quite useful to be able to ship a self-contained example
Geoserver data dir, using property stores. Where the issue is how to
use some relatively complex piece of config, such as app-schema, or
SLDs, or examples of how to invoke various output formats, or
describing advanced query capabilities and syntax, there's nothing
like a worked example.
If developers are using it needs to be documented anyway.
I'd vote to leave it in, unless there are bugs in it that are just too
hard to fix, but still allow it to be useful for testing.
Rob
On Tue, Aug 25, 2009 at 6:02 AM, Andrea Aime<aaime@anonymised.com> wrote:
Mike Pumphrey ha scritto:
Maybe we should add custom code so that the property data store
is available in the UI only if the UI is in development mode
or something?
I like this idea. Shall I JIRA?
The downside of this is that there won't be any chance
of using the property data store in a released GeoServer
(unless someone fiddles with the GS config manually).
Not sure... would like to hear the opinion of other
developers on this one.
But you can open the jira... worst case we'll solve
it as won't fix, so no big deal
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I'm -0 on this. I really see the value on providing ready to run app schema configurations, but if property datastore is such a need for them it can be a dependency on app-schema-test or something. It's not like the properties datastore is to be really used by the masses but if it's there by default people will start asking for support on an unsupported module (err, sorry, I see it's under gt/plugin now, but still... I didn't know it earned enough stars as to be there? it doesn't even show up on the module matrix: <http://docs.codehaus.org/display/GEOTOOLS/Plugin>\). PropertiesDataStore is memory bound and born only as an example of how to write a DataStore for a custom format. It won't work on a number of situations, first example comming to mind being any string value with a "|" (pipe) character. Moreover, the app-schema examples can as well be shipped with shapefiles instead of properties files, though .properties are more suited to hand edition for the sake of writing test cases, of course.
So I agree it needs to be documented, but since I guess Mike is talking about the user's docs I wonder if it's really in a shape as to be included at all?
Cheers,
Gabriel
Rob Atkinson wrote:
I think its quite useful to be able to ship a self-contained example
Geoserver data dir, using property stores. Where the issue is how to
use some relatively complex piece of config, such as app-schema, or
SLDs, or examples of how to invoke various output formats, or
describing advanced query capabilities and syntax, there's nothing
like a worked example.
If developers are using it needs to be documented anyway.
I'd vote to leave it in, unless there are bugs in it that are just too
hard to fix, but still allow it to be useful for testing.
Rob
On Tue, Aug 25, 2009 at 6:02 AM, Andrea Aime<aaime@anonymised.com> wrote:
Mike Pumphrey ha scritto:
Maybe we should add custom code so that the property data store
is available in the UI only if the UI is in development mode
or something?
I like this idea. Shall I JIRA?
The downside of this is that there won't be any chance
of using the property data store in a released GeoServer
(unless someone fiddles with the GS config manually).
Not sure... would like to hear the opinion of other
developers on this one.
But you can open the jira... worst case we'll solve
it as won't fix, so no big deal
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I would very much like to see the property data store retained in its current form. In addition to being exceptionally useful for pedagogical purposes, I can imagine intermediate-level users adding a one-point or two-point layer with some markers to a map, some bit of static data that is not handy in a database but they would like to serve to improve their maps. I can imagine little python scripts creating property files. Sure these things can grow to inefficient proportions, but just because a tool can be misused does not mean we should take it away.
It should be documented. We have made a lot of use of property file data stores, so I am in a position to document them. If you agree to keep it I will document it.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies ha scritto:
I would very much like to see the property data store retained in its current form. In addition to being exceptionally useful for pedagogical purposes, I can imagine intermediate-level users adding a one-point or two-point layer with some markers to a map, some bit of static data that is not handy in a database but they would like to serve to improve their maps. I can imagine little python scripts creating property files. Sure these things can grow to inefficient proportions, but just because a tool can be misused does not mean we should take it away.
It should be documented. We have made a lot of use of property file data stores, so I am in a position to document them. If you agree to keep it I will document it.
Summing up a bit about the idea of keeping the property data store.
Pros:
- interesting tool for anybody that wants to fiddle with external
scripts (only text manipulation required)
- easy to understand
- tendency to pop back in as a dependency, so keeping it is the
least resistance path in the long run
Cons:
- does not scale up
- confusing for end users
- lacks end user documentation
- fragile parsing
The first cons, scalability, should not really be a concern imho,
if we only shipped high performance sources we should remove ArcGrid as
well (raster data represented as text).
Actually on osgeo-discuss someone was asking for a simple text
format to store vector data (not GML). It seems to have its own
sweet spot.
The last three cons could be addressed by better documentation and
some love on the DataUtilities method that is parsing the file contents.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Well, in the meantime, I've committed a basic page about the Properties data store. Please expand on this when you have the time. Then no one will have any excuse for being confused. 
http://docs.geoserver.org/trunk/en/user/data/properties.html
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
Ben Caradoc-Davies wrote:
I would very much like to see the property data store retained in its current form. In addition to being exceptionally useful for pedagogical purposes, I can imagine intermediate-level users adding a one-point or two-point layer with some markers to a map, some bit of static data that is not handy in a database but they would like to serve to improve their maps. I can imagine little python scripts creating property files. Sure these things can grow to inefficient proportions, but just because a tool can be misused does not mean we should take it away.
It should be documented. We have made a lot of use of property file data stores, so I am in a position to document them. If you agree to keep it I will document it.
Thanks, Mike, I have added your email to the Jira issue:
http://jira.codehaus.org/browse/GEOS-3385
Mike Pumphrey wrote:
Well, in the meantime, I've committed a basic page about the Properties data store. Please expand on this when you have the time. Then no one will have any excuse for being confused.
http://docs.geoserver.org/trunk/en/user/data/properties.html
Thanks,
Mike Pumphrey
OpenGeo - http://opengeo.org
Ben Caradoc-Davies wrote:
I would very much like to see the property data store retained in its current form. In addition to being exceptionally useful for pedagogical purposes, I can imagine intermediate-level users adding a one-point or two-point layer with some markers to a map, some bit of static data that is not handy in a database but they would like to serve to improve their maps. I can imagine little python scripts creating property files. Sure these things can grow to inefficient proportions, but just because a tool can be misused does not mean we should take it away.
It should be documented. We have made a lot of use of property file data stores, so I am in a position to document them. If you agree to keep it I will document it.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia