[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [udig-devel] Postgis Datastore & Primary Keys
|
Good hunting skillz.
We should have a number of strategies to determine bounds ... some of these are rolled into a DataStore method
- if there is a spatial index we can use some kind of trick to determine an approx bounds
- we can take a random sample (basically start skipping over records) and get an approx bounds based on a subset of the data
- we can churn through all the data and build up the actual bounds (this resulted in postgis taking 3 mins to "load" in earlier versions of uDig
- and apparently now we can fall back on the CRS bounds
The code to fall back on CRS bounds would not of been tested until recently; simply because we used to use epsg-wkt which did not fill in this information. Now that we use epsg-hsql this code is probably being exercised for the first time.
I have not been following the development of the new postgis wizard; you will have to ask Jesse.
Jody
On Thu, Mar 5, 2009 at 5:51 AM, Emily Gouge
<egouge@xxxxxxxxxxxxxxx> wrote:
This was not what I expected - It seems that problem boils down to a bug in the PostgisResourceInfo.getBounds() function.
Line 84:
bounds = new
ReferencedEnvelope(new Envelope(envelope.getLowerCorner().getOrdinate(0),envelope.getLowerCorner().getOrdinate(1),envelope.getUpperCorner().getOrdinate(0),envelope.getUpperCorner().getOrdinate(1)),crs);
is incorrect. It should be :
bounds = new ReferencedEnvelope(new Envelope(envelope.getLowerCorner().getOrdinate(0),envelope.getUpperCorner().getOrdinate(0),envelope.getLowerCorner().getOrdinate(1),envelope.getUpperCorner().getOrdinate(1)),crs);
However, although this fix allows me to view tables with primary keys it does not correctly assign the bounds to the layer. The bounds of the layer are assumed to be the bounds of the coordinate reference system. So a "zoom to layer" in my case is zooming to the whole world when I only have a small portion of data.
One other thing I noticed is that the new postgis wizard only shows tables that are in the geometry_columsn table; However the catalog entry shows all tables.
Emily
Jody Garnett wrote:
Andrea Aime wrote:
The intended behaviour is to have them work read only, with the limitation that fid based filters won't work, not even read only.
But, if uDig trunk is working against the jdbc-ng plugin, and especially
a one-two months build of them, then due to a bug those were not able
to actually work on tables without a primary key. But that has been
fixed in the meantime. Remember to build geotools with -Dall if you
want a fresh build of those.
uDig trunk has not migrated to jdbc-ng yet. Emily we should check if the problem is with PostGISDataStore or with something we have done locally in the uDig build .. occasionally we have subclassed raw geotools code in order to get access to information such as the connection for our own reasons. If generating the list of tables is done in our own code there is a chance we have messed it up; if the list of tables is generated from geotools code we may of just found a regression.
Can you provide any further insight?
Jody
