Re: [JPP-Devel] Few patches for PostGIS and WMS functionality

[Ruutiainen, Jaakko]

Hi!

I have been using latest OpenJUMP from SVN and PostGIS PlugIn from 
https://sourceforge.net/project/showfiles.php?group_id=118054&package_id=179545&release_id=464883
 . There was some problems compiling PostGIS PlugIn from SVN trunk as maven 
wanted to write stuff to /home/lemeser and then properties files were missing 
something. Plugin version tagged 1.20 compiled nicely, but as we had no actual 
need for modifying the plugin, the readily available PlugIn package was 
considered sufficient. This was some weeks ago. Now I actually tested compiling 
PlugIn from trunk (rev 1420) again and it worked. Five minutes of testing and 
everything works.

File load dialog has two options for PostGIS PlugIn. For writing I mostly used 
"Insert". I don't remember now what, if any, warnings were given, definitely no 
java.lang.IllegalStateException errors then and no warning or errors for 
inserting(/updating) now.

SVN write access could come handy, but at the moment I'm not sure how much time 
I can use with OpenJUMP.

Br,
 Jaakko

> -Original Message-
> From: Stefan Steiniger [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 20, 2008 6:35 AM
> To: Ruutiainen, Jaakko
> Cc: List for discussion of JPP development and use.
> Subject: Re: [JPP-Devel] Few patches for PostGIS and WMS functionality
>
> Hei Jaakko
>
> No problem :)
>
> However, I asked Uwe on testing the current version of the
> PostGIS-Plugin and he discoverd four issues with the actual
> version (that was adapted by Eric to the new Framework, but
> based on Uwe's version).
> The three major issues where:
> - two images appear with the new file load framework
> - when trying to write to PostGIS an error message appears (see below)
> - if a table already exists then no warning for the
> overwriting appears (as it did previously) (4th and minor was
> a version difference between file name and splash-screen)
>
> Now my questions to you:
> - Do you have the same issues? (or do you use an older
> version of PlugIn and OpenJUMP)
> - Did you pulled your version from the SVN? when?
>
> I will add the patch after your answer, as I need to get sure
> that we are not talking about different versions (Otherwise I
> need to check the things in more detail).
>
> BTW: if you want, I can give you also write access to the SVN
> in case you are contracted for a longer time to solve several issues.
>
> stefan
>
> 
> error trace for writing to PostGIS
>
> java.lang.IllegalStateException: Insert statement failed:
> org.postgresql.util.PSQLException: ERROR: current transaction
> is aborted, commands ignored until end of transaction block
> INSERT INTO wald ( pktnr, baumart, baumart_lat, stamm, krone,
> hoehe, jg, vital, standort, geometry ) VALUES ( 1052,
> 'Blutbuche', 'Fagus sylvatica Atropunicea', 170, 7, 12, 1945,
> 82, '', GeometryFromText( 'POINT
> (3564178.54897135 5951709.29425931)', 0) )
>  at
> net.refractions.postgis.PostGISConnection.executeUpdate(PostGI
> SConnection.java:800)
>  at
> net.refractions.postgis.PostGISConnection.executeUpdate(PostGI
> SConnection.java:1212)
>  at
> com.vividsolutions.jump.workbench.datasource.AbstractSaveDatas
> etAsPlugIn.run(AbstractSaveDatasetAsPlugIn.java:33)
>  at
> com.vividsolutions.jump.workbench.ui.task.TaskMonitorManager$T
> askWrapper.run(TaskMonitorManager.java:149)
>  at java.lang.Thread.run(Unknown Source)
>

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] 2nd test on SLD import/export OpenJUMP, Kosmo, uDig

[Andreas Schmitz]

Giuseppe Aruta wrote:

Hi,

> I did a test on Andreas' job about import/export SLD.

thanks, your efforts are appreciated here!

> These are the resaults:
> 
> a) OpenJUMP can easly open Kosmo SLD. It imports
> everything except fill type and halo.
> Sometimes it cannot import the correct position of the
> Text

Yes, the label placement elements of SLD are not used. I think in OpenJUMP you
cannot place labels in the same way as in SLD.

> 
> b) OpenJUMP opens uDig SLD but it doesn't import the
> correct fill colour (depends to syntax of SLD, see
> later). OK for text, text color, font and  and font
> dimension. 

Are you sure? When I'm testing your files, the fill colors seem to be imported
correctly. The only thing not supported are more complicated OGC expressions
(ie, something other that a literal or a ogc:Literal). Since OpenJUMP does not
support color theming in an arbitrary manner, implementing this would be
difficult.

> d) uDig doesn't import OpenJUMP SLD. 
> When I load in uDig a SLD file from OpenJUMP, the
> screen turns to white
> (I think this depends to different syntax of SLD
> files (open SLD with a text edirtor to see it)

You probably mean this, right?:

#ffcc77

versus

#ffcc77

The example file on opengis.net
(http://schemas.opengis.net/sld/1.0.0/example-sld.xml) uses the syntax OpenJUMP
creates now, so I guess we're on the safe side ;-)

> You can see a better deatil on a EXCEL file attached
> to this mail. I also attached the shapefile I used for
> the test and the SLD files. (in TEST_ON_SLD.ZI(P))

Thanks for that, it's always nice to have more test data ;-)

Best regards, Andreas
-- 
l a t / l o n  GmbH
Aennchenstrasse 19   53177 Bonn, Germany
phone ++49 +228 18496-12 fax ++49 +228 1849629
http://www.lat-lon.dehttp://www.deegree.org

---
On June 17 is deegree day - Am 17. Juni ist deegree day
  http://deegree.org/deegreeday


signature.asc
Description: Digital signature
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] 2nd test on SLD import/export OpenJUMP, Kosmo, uDig

[Andreas Schmitz]

Giuseppe Aruta wrote:

Hi,

> > > b) OpenJUMP opens uDig SLD but it doesn't import
> > the
> > > correct fill colour .
> > 
> > Are you sure? When I'm testing your files, the fill
> > colors seem to be imported
> > correctly...
> 
> I attached two screenshot of what happens when I load
> uDig SLD in OpenJUMP
> 
> A)  1.jpg is the screenshot of the file opened in uDig
> with the style. Than saved to uDig.sld
> B)  2.jpg is the screenshot of the same file in
> OpenJUMP when I load uDig.sld

thanks, that helped.

> OpenJUMP loads colors but makes a sort of selections
> of them. According to the system of the style:
> OpenJUMP makes styles according to the value and range
> (different tones of colors) but uDig makes style
> according to "ranges" of values. 

Yes, it's similar to the color theming of OpenJUMP. They just used different
SLD/filter encoding constructs to export them to SLD. I've fixed the import, so
that it works now for these specific filters.

In general, the import will never support all possible SLD constructs, but at
least we can try to widen the range to include files such as the ones generated
by uDig.

On another note, you wrote that Halo import does not work. But I'm seeing the
Halo (at least for the Kosmo file number 2)?

Best regards, Andreas
-- 
l a t / l o n  GmbH
Aennchenstrasse 19   53177 Bonn, Germany
phone ++49 +228 18496-12 fax ++49 +228 1849629
http://www.lat-lon.dehttp://www.deegree.org

---
On June 17 is deegree day - Am 17. Juni ist deegree day
  http://deegree.org/deegreeday


signature.asc
Description: Digital signature
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Question about JTIN design decision

[Christopher]

I currently have the JTIN library designed so that all
the heavy lifting data structures are are located at
the Geometry level while all the display code is at
the Layer level.

For instance:

* TinFace extends Geometry: contains a Triangle object
and links to neighboring faces.

* TIN extends GeometryCollection: contains an array of
TinFaces and all the methods that will be used to
extract information from the TIN (like elevation
bands, or visibility matrices).

Then the TIN will be the only Geometry in a feature
and that feature will be the only one in the Layer.
The Layer will be customized so that conversion to
Java2D can happen without the overhead of generating a
massive number of throwaway LineString/Polygon classes
every time the TIN is drawn or the memory overhead of
storing such LineString/Polygon objects in the TIN
itself.

Is this the most elegant way to go about things?
Should I instead refactor things such that the TIN is
represented at the Layer level with each TinFace being
a feature? Or perhaps a third option I haven’t thought
of yet. I’m getting more familiar with the
JTS/OpenJUMP code base by the day, but I’m not
confident enough to be sure I’m taking the best tack.
Any input from JTS/OpenJUMP gurus would be
appreciated.

--Christopher


  

-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Question about JTIN design decision

[Paul Austin]

Christopher,

I would not extend Geometry for the TinFace, subclassing Geometry is not 
something that works will in the current JTS code base. I would just 
have a custom TinFace class which could be converted to Polygons if 
required for some cases. I think in a lot of cases you can forgo the 
conversion to Polygons. You could implement the CoordinateSequence 
interface on the TinFace so you reduce the amount of objects created 
when creating those polygons.


Likewise for GeometryCollection, I'm not sure if you gain anything by 
being a GeometryCollection.


For JUMP integration having it wrapped in the only feature in a layer 
doesn't add anything. Instead you could come up with an implementation 
of the Layerable inteface for rendering of TIN's, This will allow you to 
bypass all the conversions to Geometries and features. In this layerable 
you could just select the TINFaces from the TIN by bounding box and then 
render those as required. This might be a bit more work if you want to 
support styling and selecting faces/edges in the TIn but I think it 
would be a lot cleaner and you could add right click menu items specific 
to a TIN.


Just my very quick thoughts on what I'd do in your place.

Paul

*Paul Austin*
/President/CEO/
Revolution Systems Inc.

+1 (604) 288-4304 x201
www.revolsys.com 


Christopher wrote:

I currently have the JTIN library designed so that all
the heavy lifting data structures are are located at
the Geometry level while all the display code is at
the Layer level.

For instance:

* TinFace extends Geometry: contains a Triangle object
and links to neighboring faces.

* TIN extends GeometryCollection: contains an array of
TinFaces and all the methods that will be used to
extract information from the TIN (like elevation
bands, or visibility matrices).

Then the TIN will be the only Geometry in a feature
and that feature will be the only one in the Layer.
The Layer will be customized so that conversion to
Java2D can happen without the overhead of generating a
massive number of throwaway LineString/Polygon classes
every time the TIN is drawn or the memory overhead of
storing such LineString/Polygon objects in the TIN
itself.

Is this the most elegant way to go about things?
Should I instead refactor things such that the TIN is
represented at the Layer level with each TinFace being
a feature? Or perhaps a third option I haven't thought
of yet. I'm getting more familiar with the
JTS/OpenJUMP code base by the day, but I'm not
confident enough to be sure I'm taking the best tack.
Any input from JTS/OpenJUMP gurus would be
appreciated.

--Christopher


  


-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/

___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
  
-
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel