Re: [JPP-Devel] Extent calculation

2013-04-02 Thread Uwe Dalluege
Hi Michaël,

I made a small test and I can
always reproduce an error.
I think it is better to make more
tests *after* you find this bug:


1. Run this in pgAdminIII (without creating indices!):

drop table if exists t_line_invis;
CREATE TABLE t_line_invis ( lnr integer, geom geometry ( LINESTRING, 0 ) );
INSERT INTO t_line_invis VALUES
  ( 1, ST_GeometryFromText ( 'LINESTRING ( 2000.0 2000.0, 2500.0 2300.0, 
2100.0 2500.0 )', 0 ) );
INSERT INTO t_line_invis VALUES
  ( 2, ST_GeometryFromText ( 'LINESTRING ( 1000.0 1000.0, 1500.0 1300.0, 
1100.0 1500.0 )', 0 ) );

2. Start OJ (3458) with a small project-window (459, 346).

3. Open Data Store Layer and load
the table t_line_invis.

4. The error No description was provided appears.
5. Click at View/Edit Attributes.
The table is empty.
6. Zoom To Full Extent now I see the geometry
and after View/Edit Attributes the table was not empty.

7. LeftClick inside the table and the InternalError appears
(but I think, this is an old problem and has nothing to do with PostGIS):

java.lang.InternalError: Unable to Stroke shape (attempt to validate 
Pipe with invalid SurfaceData)
at sun.java2d.pipe.LoopPipe.getStrokeSpans(Unknown Source)
at sun.java2d.pipe.LoopPipe.draw(Unknown Source)
at sun.java2d.pipe.ValidatePipe.draw(Unknown Source)
at sun.java2d.SunGraphics2D.draw(Unknown Source)
at 
com.vividsolutions.jump.workbench.ui.LayerViewPanel$6.run(LayerViewPanel.java:742)
at 
com.vividsolutions.jump.workbench.ui.GUIUtil.invokeOnEventThread(GUIUtil.java:612)
at 
com.vividsolutions.jump.workbench.ui.LayerViewPanel.flash(LayerViewPanel.java:739)
at 
com.vividsolutions.jump.workbench.ui.LayerViewPanel.flash(LayerViewPanel.java:771)
at 
com.vividsolutions.jump.workbench.ui.zoom.ZoomToSelectedItemsPlugIn.flash(ZoomToSelectedItemsPlugIn.java:189)
at 
com.vividsolutions.jump.workbench.ui.AttributePanel$2.mouseClicked(AttributePanel.java:196)
at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown 
Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)



Uwe

Am 31.03.2013 14:11, schrieb Michaël Michaud:
 Hi Uwe,

 I made two improvements to try to solve the extent calculation problem
 (see r3439).

 Note : I don't know if you still have the WKB 0 bug.

 Add a VACUMM ANALYZE theNewTable after creation of a new table
 why ?
 It seems that the index creation is not enough to use ST_Estimated_Extent
 just after the table creation

 Test if the geometry column we want to use is indexed with a spatial index
 to determine if ST_Estimated_Extent or ST_Extent must be used.
 (it was quite difficult to know if a column is spatially indexed).

 Please try extensively,

 Michaël
 Hi,

 OK, I see,
 There are 2 methods to get the envelope in the code :

 ST_Estimated_Extent (fast, not precise, 

Re: [JPP-Devel] Extent calculation

2013-04-02 Thread Michaël Michaud
Hi Uwe,
 I made a small test and I can
 always reproduce an error.
 I think it is better to make more
 tests *after* you find this bug:

 1. Run this in pgAdminIII (without creating indices!):

 drop table if exists t_line_invis;
 CREATE TABLE t_line_invis ( lnr integer, geom geometry ( LINESTRING, 0 
 ) );
 INSERT INTO t_line_invis VALUES
  ( 1, ST_GeometryFromText ( 'LINESTRING ( 2000.0 2000.0, 2500.0 
 2300.0, 2100.0 2500.0 )', 0 ) );
 INSERT INTO t_line_invis VALUES
  ( 2, ST_GeometryFromText ( 'LINESTRING ( 1000.0 1000.0, 1500.0 
 1300.0, 1100.0 1500.0 )', 0 ) );

 2. Start OJ (3458) with a small project-window (459, 346).

 3. Open Data Store Layer and load
 the table t_line_invis.

 4. The error No description was provided appears.
I did not get this error. Have you more information in the log ?
Can you reproduce it always ?
 5. Click at View/Edit Attributes.
 The table is empty.
This is how datastore works : it load data intersecting the current view.
 6. Zoom To Full Extent now I see the geometry
 and after View/Edit Attributes the table was not empty.
Use the extent calculated by ST_Estimated_Extent (or ST_Extent) and
load features intersecting the extent (all the features)

 7. LeftClick inside the table and the InternalError appears
 (but I think, this is an old problem and has nothing to do with PostGIS):
Yes, an old problem appearing sometimes the first time OJ tries to drow 
a shape.

Except 4. that I can't reproduce, and the following Stroke bug, other
behaviour is desired.
As I've already said, we could include zoom to full extent just after 
setting
a connection to a new dataset, but It would make impossible to connect
to a dataset containing millions of features.
An improvement could be to zoom to the first feature...

Michaël


 java.lang.InternalError: Unable to Stroke shape (attempt to validate 
 Pipe with invalid SurfaceData)
 at sun.java2d.pipe.LoopPipe.getStrokeSpans(Unknown Source)
 at sun.java2d.pipe.LoopPipe.draw(Unknown Source)
 at sun.java2d.pipe.ValidatePipe.draw(Unknown Source)
 at sun.java2d.SunGraphics2D.draw(Unknown Source)
 at 
 com.vividsolutions.jump.workbench.ui.LayerViewPanel$6.run(LayerViewPanel.java:742)
 at 
 com.vividsolutions.jump.workbench.ui.GUIUtil.invokeOnEventThread(GUIUtil.java:612)
 at 
 com.vividsolutions.jump.workbench.ui.LayerViewPanel.flash(LayerViewPanel.java:739)
 at 
 com.vividsolutions.jump.workbench.ui.LayerViewPanel.flash(LayerViewPanel.java:771)
 at 
 com.vividsolutions.jump.workbench.ui.zoom.ZoomToSelectedItemsPlugIn.flash(ZoomToSelectedItemsPlugIn.java:189)
 at 
 com.vividsolutions.jump.workbench.ui.AttributePanel$2.mouseClicked(AttributePanel.java:196)
 at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
 at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
 at java.awt.AWTEventMulticaster.mouseClicked(Unknown Source)
 at java.awt.Component.processMouseEvent(Unknown Source)
 at javax.swing.JComponent.processMouseEvent(Unknown Source)
 at java.awt.Component.processEvent(Unknown Source)
 at java.awt.Container.processEvent(Unknown Source)
 at java.awt.Component.dispatchEventImpl(Unknown Source)
 at java.awt.Container.dispatchEventImpl(Unknown Source)
 at java.awt.Component.dispatchEvent(Unknown Source)
 at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
 at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
 at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
 at java.awt.Container.dispatchEventImpl(Unknown Source)
 at java.awt.Window.dispatchEventImpl(Unknown Source)
 at java.awt.Component.dispatchEvent(Unknown Source)
 at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
 at java.awt.EventQueue.access$200(Unknown Source)
 at java.awt.EventQueue$3.run(Unknown Source)
 at java.awt.EventQueue$3.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
 java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
 at 
 java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
 at java.awt.EventQueue$4.run(Unknown Source)
 at java.awt.EventQueue$4.run(Unknown Source)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
 java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
 at java.awt.EventQueue.dispatchEvent(Unknown Source)
 at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown 
 Source)
 at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
 at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown 
 Source)
 at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
 at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
 at java.awt.EventDispatchThread.run(Unknown Source)



 Uwe

 Am 31.03.2013 14:11, schrieb Michaël Michaud:
 Hi Uwe,

 I made two improvements to try to solve the 

Re: [JPP-Devel] Extent calculation

2013-04-02 Thread Uwe Dalluege
Hi Michaël,

Am 02.04.2013 20:40, schrieb Michaël Michaud:
 Hi Uwe,
 I made a small test and I can
 always reproduce an error.
 I think it is better to make more
 tests *after* you find this bug:

 1. Run this in pgAdminIII (without creating indices!):

 drop table if exists t_line_invis;
 CREATE TABLE t_line_invis ( lnr integer, geom geometry ( LINESTRING, 0
 ) );
 INSERT INTO t_line_invis VALUES
  ( 1, ST_GeometryFromText ( 'LINESTRING ( 2000.0 2000.0, 2500.0
 2300.0, 2100.0 2500.0 )', 0 ) );
 INSERT INTO t_line_invis VALUES
  ( 2, ST_GeometryFromText ( 'LINESTRING ( 1000.0 1000.0, 1500.0
 1300.0, 1100.0 1500.0 )', 0 ) );

 2. Start OJ (3458) with a small project-window (459, 346).

 3. Open Data Store Layer and load
 the table t_line_invis.

 4. The error No description was provided appears.
 I did not get this error. Have you more information in the log ?
 Can you reproduce it always ?

Yes, I can reproduce it always. Here is my log-file:

2013-04-03 07:17:41,307  WARN class 
org.openjump.core.ui.plugin.file.SaveImageAsSVGPlugIn could not be 
initialized
2013-04-03 07:17:41,307  INFO java.lang.NoClassDefFoundError: 
org/apache/batik/svggen/SVGGraphics2D
2013-04-03 07:17:42,898  WARN ECW loader class 
com.ermapper.ecw.JNCSRenderer not installed.
2013-04-03 07:17:42,914  WARN ECW loader class 
com.ermapper.ecw.JNCSRenderer not installed.
2013-04-03 07:17:42,914  WARN lib\ext\etc\mrsidgeodecode.exe not installed.
2013-04-03 07:17:43,452  INFO Activating Select Features Tool
2013-04-03 07:17:43,452  INFO Activating Select Features Tool
2013-04-03 07:17:43,452  INFO Activating Select Features Tool
2013-04-03 07:17:45,784  INFO Executing Open...
2013-04-03 07:17:52,149  INFO Done. Current committed memory: 35 MB
2013-04-03 07:17:52,149  INFO Activating Select Features Tool
2013-04-03 07:19:12,582  WARN class 
org.openjump.core.ui.plugin.file.SaveImageAsSVGPlugIn could not be 
initialized
2013-04-03 07:19:12,582  INFO java.lang.NoClassDefFoundError: 
org/apache/batik/svggen/SVGGraphics2D
2013-04-03 07:19:14,096  WARN ECW loader class 
com.ermapper.ecw.JNCSRenderer not installed.
2013-04-03 07:19:14,096  WARN ECW loader class 
com.ermapper.ecw.JNCSRenderer not installed.
2013-04-03 07:19:14,111  WARN lib\ext\etc\mrsidgeodecode.exe not installed.
2013-04-03 07:19:14,649  INFO Activating Select Features Tool
2013-04-03 07:19:14,649  INFO Activating Select Features Tool
2013-04-03 07:19:14,649  INFO Activating Select Features Tool
2013-04-03 07:19:17,980  INFO Executing Open...
2013-04-03 07:19:22,894  INFO Executing Retrieving list of datasets.
2013-04-03 07:19:23,050  INFO Done. Current committed memory: 44 MB
2013-04-03 07:19:29,774  INFO Executing Retrieving list of geometry 
attributes.
2013-04-03 07:19:29,852  INFO Done. Current committed memory: 45 MB
2013-04-03 07:19:31,864  INFO Activating Select Features Tool
2013-04-03 07:19:31,973  INFO Done. Current committed memory: 48 MB
2013-04-03 07:19:32,005  INFO Activating Select Features Tool
2013-04-03 07:19:32,051  INFO Warning: No description was provided.

  (No Such Element Exception)


 5. Click at View/Edit Attributes.
 The table is empty.
 This is how datastore works : it load data intersecting the current view.
 6. Zoom To Full Extent now I see the geometry
 and after View/Edit Attributes the table was not empty.
 Use the extent calculated by ST_Estimated_Extent (or ST_Extent) and
 load features intersecting the extent (all the features)

 7. LeftClick inside the table and the InternalError appears
 (but I think, this is an old problem and has nothing to do with PostGIS):
 Yes, an old problem appearing sometimes the first time OJ tries to drow
 a shape.

 Except 4. that I can't reproduce, and the following Stroke bug, other
 behaviour is desired.
 As I've already said, we could include zoom to full extent just after
 setting
 a connection to a new dataset, but It would make impossible to connect
 to a dataset containing millions of features.
 An improvement could be to zoom to the first feature...

Maybe you can count the rows in the table
and if there are more than millions or so, you can avoid to zoom?

What do you think?

Uwe


 Michaël


 java.lang.InternalError: Unable to Stroke shape (attempt to validate
 Pipe with invalid SurfaceData)
 at sun.java2d.pipe.LoopPipe.getStrokeSpans(Unknown Source)
 at sun.java2d.pipe.LoopPipe.draw(Unknown Source)
 at sun.java2d.pipe.ValidatePipe.draw(Unknown Source)
 at sun.java2d.SunGraphics2D.draw(Unknown Source)
 at
 com.vividsolutions.jump.workbench.ui.LayerViewPanel$6.run(LayerViewPanel.java:742)

 at
 com.vividsolutions.jump.workbench.ui.GUIUtil.invokeOnEventThread(GUIUtil.java:612)

 at
 com.vividsolutions.jump.workbench.ui.LayerViewPanel.flash(LayerViewPanel.java:739)

 at
 com.vividsolutions.jump.workbench.ui.LayerViewPanel.flash(LayerViewPanel.java:771)

 at
 com.vividsolutions.jump.workbench.ui.zoom.ZoomToSelectedItemsPlugIn.flash(ZoomToSelectedItemsPlugIn.java:189)


Re: [JPP-Devel] Extent calculation

2013-03-31 Thread Michaël Michaud
Hi Uwe,

I made two improvements to try to solve the extent calculation problem
(see r3439).

Note : I don't know if you still have the WKB 0 bug.

Add a VACUMM ANALYZE theNewTable after creation of a new table
why ?
It seems that the index creation is not enough to use ST_Estimated_Extent
just after the table creation

Test if the geometry column we want to use is indexed with a spatial index
to determine if ST_Estimated_Extent or ST_Extent must be used.
(it was quite difficult to know if a column is spatially indexed).

Please try extensively,

Michaël
 Hi,

 OK, I see,
 There are 2 methods to get the envelope in the code :

 ST_Estimated_Extent (fast, not precise, based on index)
 ST_Extent (slow, precise)

 Currently, we switch on second method if first one throws an exception
 (don't know in which circumstances exactly)

 I can see if I can add a test on spatial index existence and switch
 also to second method if there is no spatial index.

 Michaël

 Hi Jukka,

 Bingo!!!
 That was the 100 000 000,- euro idea!

 create index on t_line_invis using gist ( geom );

 Now I see the geometries in openjump.

 But I see a problem with small tables creating
 without indices.
 What can we do with this?

 Uwe


 Am 28.03.2013 08:25, schrieb Rahkonen Jukka:
 Hi Uwe,

 Try to add spatial index to your test tables and see what happens then.  
 OpenJUMP is doing query as
 SELECT ST_AsBinary(ST_Estimated_Extent)
 It is fast and I think the right way to do it in OpenJUMP but I do not 
 believe that it can work work without spatial index.
 http://postgis.refractions.net/documentation/manual-1.4/ST_Estimated_Extent.html

 -Jukka-


 
 Lähettäjä: Uwe Dalluege [uwe.dallu...@hcu-hamburg.de]
 Lähetetty: 28. maaliskuuta 2013 8:29
 Vastaanottaja: OpenJump develop and use
 Cc: Michaël Michaud
 Aihe: Re: [JPP-Devel] Unknown WKB type 0 and change coord_dimension

 Hi Michaël,

 I see it is not so easy to find this bug.
 I will make some other tests and let you know.

 But have you tried my test I have posted at 26.03.2013
 (PostGIS Layer invisible; Zoom To Full Extent)?

 ...

 I have a problem with Zoom To Full Extent
 with the new PostGIS reader!
 Using PostgreSQL 9.2.1 with PostGIS 2.0.

 I created two tables with SQL.

 This table (t_line) works fine:

 drop table if exists t_line;
 CREATE TABLE t_line ( lnr integer, geom geometry ( LINESTRING, 0 ) );
 INSERT INTO t_line VALUES
   ( 1, ST_GeometryFromText ( 'LINESTRING ( 200.0 200.0, 250.0 230.0,
 210.0 250.0 )', 0 ) );
 INSERT INTO t_line VALUES
   ( 2, ST_GeometryFromText ( 'LINESTRING ( 100.0 100.0, 150.0 130.0,
 110.0 150.0 )', 0 ) );

 SELECT * FROM t_line;


 This table (t_line_invis) is invisible after Zoom To Full Extent:

 drop table if exists t_line_invis;
 CREATE TABLE t_line_invis ( lnr integer, geom geometry ( LINESTRING, 0 ) );
 INSERT INTO t_line_invis VALUES
   ( 1, ST_GeometryFromText ( 'LINESTRING ( 2000.0 2000.0, 2500.0 2300.0,
 2100.0 2500.0 )', 0 ) );
 INSERT INTO t_line_invis VALUES
   ( 2, ST_GeometryFromText ( 'LINESTRING ( 1000.0 1000.0, 1500.0 1300.0,
 1100.0 1500.0 )', 0 ) );

 SELECT * FROM t_line_invis;
 ...

 Uwe

 Am 27.03.2013 19:36, schrieb Michaël Michaud:
 Hi,

 I can't see the WKB type 0 problem in the above sequence.
 Is it solved or is it repeatable with another sequence.

 No, I do not tested it with r3404+
 but I done the modification inside the source code.

 Now I test r3412.
 Do you made the modification in r3412?

 I see that the coord_dimension has changed from 2 to 3:


 1. I open my project GeoCity with a .jml layer
 Wohngebiet.
 Did you change the dataset ? (I used Gebaeudeprivat instead)
 2. Saving this jml-layer to PostGIS.
 3. Close OpenJUMP (important)!
 4. Start OJ again and open the table Wohngebiet
 in PostGIS
 5. No Such Element Exception
 and I see no geometries
 I could not reproduce this today, but I have seen that before.
 I have already tried to find a solution but it's a bit tricky.
 I think we will have to live with it some time...
 6. Zoom To Full Extent and I see the geometries.
 As I told you, full extent of a database layer can contains too
 many features for OpenJUMP, and I think it is more safe not
 to do it automatically after the first import. If it is not down,
 the layer may be empty (probably related to the No such
 element exception though)
 7. Now I load the table again and there is no more
 the error No Such Element Exception.
 And after the first Zoom to extent, the driver extracts data
 in a zone where there IS data.
 8. Close OJ.
 9. Start OJ and load the table Wohngebiet.
 10. The error No Such Element Exception appears.
 11. Set srid to 31467 to the layer Wohngebiet.
 12. Save the PostGIS layer Wohngebiet under a new name wg31467.
 13. The coord_dimension of wg31467 is not 2 but 3!
 According to my tests and to the code the geometry coord dimension
 should be 2, but there may be strange behaviour as the code tests a
 few geometries and