Hi,
I've just noticed that CatalogBuilder computes on
its own the native bbox while creating FeatureTypeInfo objects.
This is a big no-no when dealing with bigger datasets, as it
may lockup GeoServer for minutes.
I would like to remove that computation, but not sure what
the side effects might be, I guess I may end up breaking
something in the RESTConfig configuration?
RESTConfig should also allow the user to decide wheter
to compute the native bbox, or just use the provided lat/lon
bbox
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hi Andrea,
I thought those would catch your eye ;). And my rationale was not to be irresponsible, i fully realize the repercussions. But... in this case (the RESTful case) the user is creating a new feature type. When the user creates the new feature type they have the option of specifying the bounding box and the computation only happens when they do not. So in this case it is really the user asking for what they get since they did not specify the bounding box. Now that happens in initFeatureType(FeatureTypeInfo)
There is also a bounds computation buildFeatureSource(FeatureSource) which is also called by REST when a shapefile (or some other vector file) is uploaded. Now again the user has the ability to prevent this by requesting that no automatic configuration take place, and then they can manually specifying the bounding box (either native or lat lon) later.
So in both cases the user has the choice and can avoid the bounds computation. Although I do admit in both cases it would be pretty easy for the computation to occur by default. In the first case I would not be against throwing an exception if they don't specify the bounding box... or making them explicitly set a parameter which allows us to compute it. The second case would be hard... it would more or less kill the "upload shapefile and go" use case.
-Justin
Andrea Aime wrote:
Hi,
I've just noticed that CatalogBuilder computes on
its own the native bbox while creating FeatureTypeInfo objects.
This is a big no-no when dealing with bigger datasets, as it
may lockup GeoServer for minutes.
I would like to remove that computation, but not sure what
the side effects might be, I guess I may end up breaking
something in the RESTConfig configuration?
RESTConfig should also allow the user to decide wheter
to compute the native bbox, or just use the provided lat/lon
bbox
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi Andrea,
I thought those would catch your eye ;). And my rationale was not to be irresponsible, i fully realize the repercussions. But... in this case (the RESTful case) the user is creating a new feature type. When the user creates the new feature type they have the option of specifying the bounding box and the computation only happens when they do not. So in this case it is really the user asking for what they get since they did not specify the bounding box. Now that happens in initFeatureType(FeatureTypeInfo)
There is also a bounds computation buildFeatureSource(FeatureSource) which is also called by REST when a shapefile (or some other vector file) is uploaded. Now again the user has the ability to prevent this by requesting that no automatic configuration take place, and then they can manually specifying the bounding box (either native or lat lon) later.
So in both cases the user has the choice and can avoid the bounds computation. Although I do admit in both cases it would be pretty easy for the computation to occur by default. In the first case I would not be against throwing an exception if they don't specify the bounding box... or making them explicitly set a parameter which allows us to compute it. The second case would be hard... it would more or less kill the "upload shapefile and go" use case.
Ok, nice to know it's possible to avoid "death by bbox computation"
in the RESTful case. That still leaves me cold in the UI case thought,
the UI code also needs to build FeatureTypeInfo/CoverageInfo from
a FeatureSource to pre-fill some of the fields in the UI.
So... should I add a "computeBBOX" boolean flag to the methods that
do build a FeatureTypeInfo or a CoverageInfo?
And I'll also need to add an explicit method to compute the native
bbox given a ResourceInfo (or two, one for feature types and one for
coverages)
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi Andrea,
I thought those would catch your eye ;). And my rationale was not to be irresponsible, i fully realize the repercussions. But... in this case (the RESTful case) the user is creating a new feature type. When the user creates the new feature type they have the option of specifying the bounding box and the computation only happens when they do not. So in this case it is really the user asking for what they get since they did not specify the bounding box. Now that happens in initFeatureType(FeatureTypeInfo)
There is also a bounds computation buildFeatureSource(FeatureSource) which is also called by REST when a shapefile (or some other vector file) is uploaded. Now again the user has the ability to prevent this by requesting that no automatic configuration take place, and then they can manually specifying the bounding box (either native or lat lon) later.
So in both cases the user has the choice and can avoid the bounds computation. Although I do admit in both cases it would be pretty easy for the computation to occur by default. In the first case I would not be against throwing an exception if they don't specify the bounding box... or making them explicitly set a parameter which allows us to compute it. The second case would be hard... it would more or less kill the "upload shapefile and go" use case.
Ok, nice to know it's possible to avoid "death by bbox computation"
in the RESTful case. That still leaves me cold in the UI case thought,
the UI code also needs to build FeatureTypeInfo/CoverageInfo from
a FeatureSource to pre-fill some of the fields in the UI.
So... should I add a "computeBBOX" boolean flag to the methods that
do build a FeatureTypeInfo or a CoverageInfo?
And I'll also need to add an explicit method to compute the native
bbox given a ResourceInfo (or two, one for feature types and one for
coverages)
Sounds good to me, and if you want to make it not compute the bounding box by default i am fine with that. Just ping me when you commit the changes and I will update the RESTConfig module. Oh wait, not on trunk. I should probably port it to trunk sooner rather than later.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.