I just noticed that we have a couple extra datastore extensions that were included in the 1.5 release, ones that were included as extras to be downloaded separately. The one I noticed is the GML Datastore, and another one that hasn't been included as an extra before: the Directory Datastore. Are we wanting these in the official release? Are they stable enough?
I think it was just an accident that they got in there, but if not let me know.
--
Brent Owens
(The Open Planning Project)
Brent Owens ha scritto:
I just noticed that we have a couple extra datastore extensions that were included in the 1.5 release, ones that were included as extras to be downloaded separately. The one I noticed is the GML Datastore, and another one that hasn't been included as an extra before: the Directory Datastore. Are we wanting these in the official release? Are they stable enough?
Don't know about the GML data store, but the directory data store
is something I would have loved to include, but unfortunately we cannot
because we're unable to configure it: among parameters it requires an array of file extensions, and we should adjust the user interface parsing code to turn a list of space separated strings into an array (or have the datastore accept and parse a plain string instead).
Jody, you're the directory data store maintainer. Comments on the parameter change? How would it handle a situation where we have both shapefile ds and indexed shapefile one? Is anyone using it, btw?
Cheers
Andrea
Andrea Aime wrote:
Brent Owens ha scritto:
I just noticed that we have a couple extra datastore extensions that were included in the 1.5 release, ones that were included as extras to be downloaded separately. The one I noticed is the GML Datastore, and another one that hasn't been included as an extra before: the Directory Datastore. Are we wanting these in the official release? Are they stable enough?
Don't know about the GML data store, but the directory data store
is something I would have loved to include, but unfortunately we cannot
because we're unable to configure it: among parameters it requires an array of file extensions, and we should adjust the user interface parsing code to turn a list of space separated strings into an array (or have the datastore accept and parse a plain string instead).Jody, you're the directory data store maintainer. Comments on the parameter change? How would it handle a situation where we have both shapefile ds and indexed shapefile one? Is anyone using it, btw?
Nobody is using the directory datastore - except test cases. It is a great way to slurp up a director of data to test against! In general the catalog idea has taken over in real world use.
For the case of the single shapefile the datastore factories get to fight over handing the result, you would have to play with the hint system to prefer one over the other. I think the original shapefile ds can be retired now? (Jesse?)
Jody
Jody Garnett ha scritto:
Andrea Aime wrote:
Brent Owens ha scritto:
I just noticed that we have a couple extra datastore extensions that were included in the 1.5 release, ones that were included as extras to be downloaded separately. The one I noticed is the GML Datastore, and another one that hasn't been included as an extra before: the Directory Datastore. Are we wanting these in the official release? Are they stable enough?
Don't know about the GML data store, but the directory data store
is something I would have loved to include, but unfortunately we cannot
because we're unable to configure it: among parameters it requires an array of file extensions, and we should adjust the user interface parsing code to turn a list of space separated strings into an array (or have the datastore accept and parse a plain string instead).Jody, you're the directory data store maintainer. Comments on the parameter change? How would it handle a situation where we have both shapefile ds and indexed shapefile one? Is anyone using it, btw?
Nobody is using the directory datastore - except test cases. It is a great way to slurp up a director of data to test against! In general the catalog idea has taken over in real world use.
Populating a catalog file by file is crazy, what if you had some 1000
files? Directory data store seems a low cost solution for people
having tons of shapefiles around. At least they "only" have to
configure feature types by hand this way (which is still too much
work imho, but let's move this to the new UI).
For the case of the single shapefile the datastore factories get to fight over handing the result, you would have to play with the hint system to prefer one over the other. I think the original shapefile ds can be retired now? (Jesse?)
Are the issues with writing and file locks on windows fixed?
Cheers
Andrea
Andrea Aime wrote:
Jody Garnett ha scritto:
Jody, you're the directory data store maintainer. Comments on the parameter change? How would it handle a situation where we have both shapefile ds and indexed shapefile one? Is anyone using it, btw?
Nobody is using the directory datastore - except test cases. It is a great way to slurp up a director of data to test against! In general the catalog idea has taken over in real world use.
Populating a catalog file by file is crazy, what if you had some 1000 files?
Um that was my point - making a catalog that slurps up a directory is the better approach (rather then a single datastore .. after all you may get type conflicts).
Directory data store seems a low cost solution for people having tons of shapefiles around. At least they "only" have to configure feature types by hand this way (which is still too much work imho, but let's move this to the new UI).
Agreed - directory datastore was design in mind with a UI of checkboxes to "publish" discovered FeatureTypes.
Jody
Hi Andrea got some answers by virtue of taking Jesse to coffee.
Apparently the original ShapefileDataStore can be retired (constructors set to protected, factory unplugged etc...), although perhaps it would be nicer to merge the two implementations.
Jody
Andrea Aime wrote:
For the case of the single shapefile the datastore factories get to fight over handing the result, you would have to play with the hint system to prefer one over the other. I think the original shapefile ds can be retired now? (Jesse?)
Are the issues with writing and file locks on windows fixed?
Cheers
Andrea
Merge or just rename - either way the IndexedShapefileDataStore should be named ShapefileDataStore. The index is an option in the factory to turn off or on.
+1 on this, I've been trying to push for it for a long time, since that was always the intent of the indexedshapefile.
C
Jody Garnett wrote:
Hi Andrea got some answers by virtue of taking Jesse to coffee.
Apparently the original ShapefileDataStore can be retired (constructors set to protected, factory unplugged etc...), although perhaps it would be nicer to merge the two implementations.
Jody
Andrea Aime wrote:
For the case of the single shapefile the datastore factories get to fight over handing the result, you would have to play with the hint system to prefer one over the other. I think the original shapefile ds can be retired now? (Jesse?)
Are the issues with writing and file locks on windows fixed?
Cheers
Andrea-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel!DSPAM:1003,45dde08028236309890654!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org