OpenJUMP Wiki - User contributions [en]

Using OpenJump in Your Student Project

2010-04-26T21:45:45Z

Beckerl: Created page with '== So you're thinking of using OpenJUMP in your student project == Is this a good idea? If you can match the scope of the task to your available timetable, it can be. A good ru…'

== So you're thinking of using OpenJUMP in your student project ==

Is this a good idea? If you can match the scope of the task to your available timetable, it can be. A good rule of thumb to follow is avoid trying to create totally new capabilities. A student project should be original, but not groundbreaking. It should do something that can't easily be done with existing OpenJUMP commands, but don't choose something that requires an intense study of undocumented interfaces.

Developing with OpenJUMP

2010-04-26T21:31:52Z

Beckerl:

* [[How to get OpenJUMP source code]]
* [[Developer Documentation and HowTo]]
* "Developer Mailing List":https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
* "Bug Tracker":https://sourceforge.net/tracker/?group_id=118054
* "SVN": http://sourceforge.net/svn/?group_id=118054
* [[Internationalization]]
* [[How to translate OpenJUMP into another language]]
* [[Notes on Speed Improvements on Rendering]]
* [[Using OpenJump in Your Student Project]]
<br>
* [[OpenJUMP Google Summer Of Code]]
* [[JTin Google Summer of Code 2008]]
* [[Scripting with BeanShell]]

Google Summer Of Code Ideas List

2010-03-09T14:11:45Z

Beckerl:

Below is a list of topics for a [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#org_is Google summer of code project]. However, several of those topics need to be evaluated for their fitness, i.e. a sufficient degree of innovation. We also need to look which of those topics would enhance OpenJUMP Vector editing and analysis strength, and which topics are urgently needed to complete the set of standard GIS functionality.

'''Notes''':
# GSofC student applications are from *March 29th to April 9th*. (Mentoring applications are due March 8th-12th)
# All projects require a "decent" knowledge of programming in JAVA. Certain topics require even advanced Java knowledge (i.e. the topics involving databases). An introduction to development with OpenJUMP will be given by us.
# The time of the GSofC is [http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline given] from May 24th to August 16th, i.e. three months

== List of Possible Topics 2010 ==

* Continuing work on the JTIN library that allows OpenJUMP to work with TIN data. Special focus on publishing functional plug-ins for existing code, and on enhancing JTIN to work with extra-large data sources - JTin should use now JTS 1.11 functions. (sstein - '''Priority Topic''', lbecker +1)
* Work on adding support for "external" tables (non-spatial features) in OpenJUMP.
* Work on routing plug-in for OpenJUMP.
* Work on upgrades of OpenJUMP core. This would include adding support for new Java language features and splitting the program "model" from the GUI. E.g. implementing a docking framework.
* Work on angle and direction support for JTS Warped library. (sstein: not sure what is meant here)
* Work on precision CAD drawing and modification tools for OpenJUMP.
* Work on support for cartographic map production from OpenJUMP using open source tools like Scribus and Inkscape. (Focus on enabling export of Inkscape compatible SCG from OpenJUMP.)
* Integrate cartographic projections support into OpenJUMP core (using deegree, geotools or ''Proj4J'' libraries). (sstein - '''Priority Topic''', lbecker +1)
* Continuing Work on an abstract data layer and a model that allows to store data in the H2 database. This way OpenJUMP should be enabled to work also with large datasets and not only datasets that can be load into the memory. (sstein - '''Priority Topic''', lbecker +1).
* Implementation of (explorative) statistics tools (charts and graphs) for data analysis and reporting (see for instance GeoDa and [http://www.jfree.org/jfreechart/ JFreeChart]).
* Implementing build-in write support for databases such as SpatialLite, PostGIS, Oracle and MySQL that allows all-at-once but also incremental writing (see gvSIG implementations).
* Continuing developments of a Web Processing Service (WPS) plugin for OpenJUMP and a server based on OpenJUMP functionality (see WebGEN by Moritz Neun and Theodor Foerster). (sstein - '''Priority Topic''').
* Integration of a help system for (analysis) functions.
* Improving text labeling options (see gvSIG plugin).
* Creating a draft and proptype of "OpenJUMP Mobile" for data creation and editing in the field. This involves in particular the design of a new GUI that allows to use existing mechanisms.
* Extend OJs core so that annotations can be stored including images and web links (similar to Google Maps Push Pins).
* Implement a default-settings/ini-file system to allow OpenJUMP to be used in larger business operations. (sstein: not sure if that is a 3 months task)
* Multi criteria decision analysis Tools for OpenJUMP
* JEQL for OpenJUMP (?)
* Integrating Sextantes toolbox model and Flow-Chart-Modeller in OpenJUMP

If you are interested in one of those topics please write to Landon (sunburned.surveyor[.at.]gmail.com) or Stefan (sstein[.at.]geo.uzh.ch) or even better: write both.

Beanshell:Setting Scale Bar options

2010-02-17T14:45:48Z

Beckerl:

== Scale Bar script options adapt the scale bar==

setBAR_HEIGHT(int bar_height)

setFILL1(Color fill1)

setFILL2(Color fill2)

//Predefined Colors: black, blue, cyan, darkGray, gray, green, lightGray, magenta, orange, pink, red, white, yellow

setHORIZONTAL_MARGIN(int horizontal_margin)

setLINE_COLOR(Color line_color)

setTEXT_BOTTOM_MARGIN(int text_bottom_margin)

setFONT(new Font("Dialog", Font.BOLD, 14))

//Allowed Fonts: Dialog, DialogInput, Monospaced, Serif, SansSerif
//Font style: PLAIN, ITALIC, BOLD

setTEXT_COLOR(Color text_color)

setUNIT_TEXT_BOTTOM_MARGIN(int unit_text_bottom_margin)

setUNIT_TEXT_COLOR(Color unit_text_color)

setVERTICAL_MARGIN(int vertical_margin)

== Example script to set Scale Bar options ==

{
import com.vividsolutions.jump.workbench.ui.plugin.scalebar.ScaleBarRenderer;
import java.awt.Font;
ScaleBarRenderer.setBAR_HEIGHT(13);
ScaleBarRenderer.setFILL1(Color.white);
ScaleBarRenderer.setFILL2(Color.lightGray);
ScaleBarRenderer.setTEXT_COLOR(Color.black);
ScaleBarRenderer.setFONT(new Font("Dialog", Font.BOLD, 12));
ScaleBarRenderer.setUNIT_FONT(new Font("Dialog", Font.BOLD, 12));
ScaleBarRenderer.setUNIT_TEXT_COLOR(Color.black);
ScaleBarRenderer.setVERTICAL_MARGIN(5);
ScaleBarRenderer.setHORIZONTAL_MARGIN(5);
}

Beanshell:Setting Scale Bar options

2010-02-17T14:43:39Z

Beckerl:

== Scale Bar script options adapt the scale bar==

setBAR_HEIGHT(int bar_height)
setFILL1(Color fill1)
setFILL2(Color fill2)
//Predefined Colors: black, blue, cyan, darkGray, gray, green, lightGray, magenta, orange, pink, red, white, yellow
setHORIZONTAL_MARGIN(int horizontal_margin)
setLINE_COLOR(Color line_color)
setTEXT_BOTTOM_MARGIN(int text_bottom_margin)
setFONT(new Font("Dialog", Font.BOLD, 14))
//Allowed Fonts: Dialog, DialogInput, Monospaced, Serif, SansSerif
//Font style: PLAIN, ITALIC, BOLD
setTEXT_COLOR(Color text_color)
setUNIT_TEXT_BOTTOM_MARGIN(int unit_text_bottom_margin)
setUNIT_TEXT_COLOR(Color unit_text_color)
setVERTICAL_MARGIN(int vertical_margin)

== Example script to set Scale Bar options ==

{
import com.vividsolutions.jump.workbench.ui.plugin.scalebar.ScaleBarRenderer;
import java.awt.Font;
ScaleBarRenderer.setBAR_HEIGHT(13);
ScaleBarRenderer.setFILL1(Color.white);
ScaleBarRenderer.setFILL2(Color.lightGray);
ScaleBarRenderer.setTEXT_COLOR(Color.black);
ScaleBarRenderer.setFONT(new Font("Dialog", Font.BOLD, 12));
ScaleBarRenderer.setUNIT_FONT(new Font("Dialog", Font.BOLD, 12));
ScaleBarRenderer.setUNIT_TEXT_COLOR(Color.black);
ScaleBarRenderer.setVERTICAL_MARGIN(5);
ScaleBarRenderer.setHORIZONTAL_MARGIN(5);
}

== Predefined colors are ==

black, blue, cyan, darkGray, gray,green, lightGray, magenta, orange, pink, red, white, yellow

Beanshell:Setting Scale Bar options

2010-02-17T14:40:02Z

Beckerl: Created page with '== Example script to set Scale Bar options == { import com.vividsolutions.jump.workbench.ui.plugin.scalebar.ScaleBarRenderer; import java.awt.Font; ScaleBarRenderer.setBAR_HE…'

== Example script to set Scale Bar options ==

{
import com.vividsolutions.jump.workbench.ui.plugin.scalebar.ScaleBarRenderer;
import java.awt.Font;
ScaleBarRenderer.setBAR_HEIGHT(13);
ScaleBarRenderer.setFILL1(Color.white);
ScaleBarRenderer.setFILL2(Color.lightGray);
ScaleBarRenderer.setTEXT_COLOR(Color.black);
ScaleBarRenderer.setFONT(new Font("Dialog", Font.BOLD, 12));
ScaleBarRenderer.setUNIT_FONT(new Font("Dialog", Font.BOLD, 12));
ScaleBarRenderer.setUNIT_TEXT_COLOR(Color.black);
ScaleBarRenderer.setVERTICAL_MARGIN(5);
ScaleBarRenderer.setHORIZONTAL_MARGIN(5);
}

== Predefined colors are ==

black, blue, cyan, darkGray, gray,green, lightGray, magenta, orange, pink, red, white, yellow

Scripting with BeanShell

2010-02-17T14:30:16Z

Beckerl:

== What is BeanShell? ==

BeanShell is a small, free, embeddable Java source interpreter with object scripting language features, written in Java. BeanShell dynamically executes standard Java syntax and extends it with common scripting conveniences such as loose types, commands, and method closures like those in Perl and JavaScript.

In the context of Jump, BeanShell enables the automation of repetative tasks or to accomplish tasks that are not possible using the GUI without the need for plugin modules or modification of the application source code.

See http://www.beanshell.org/ for more information on BeanShell.

== BeanShell in OpenJUMP ==

To open the BeanShell scripting window select the following menu option:

View -> BeanShell...

It is a good idea to surround all your scripts in a set of braces. I.e.

{
script...
}

In BeanShell you may access JavaBean properties as if they were fields. For example ''wc.layerManager'' is the same as ''wc.getLayerManager()''.

There is no facility to save and load a script. If you plan to reuse your scripts, develop the script in a text editor and then paste into the BeanShell window as needed.

If you want to write Beanshell scripts you can also use the [http://geo.michaelm.free.fr/OpenJUMP/resources/bsheditor4jump.jar Beanshell-Editor-JUMP Plugin] that has been written by Michael Michaud.

== JUMP BeanShell examples ==

Some of the following scripts are not very useful. Instead they are indented as examples which can be easily adapted to perform useful tasks.

* [[Beanshell:Saving View as Image]]
* [[Beanshell:Loading an Image into the task]]
* [[Beanshell:Toggle Layer Visibility]]
* [[Beanshell:Set an attribute fore every feature of a Layer]]
* [[Beanshell:Combine two selected layers]]
* [[Beanshell:Replace point symbols with green pushpin]]
* [[Beanshell:Removing repeated points in selected layers feature geometries]]
* [[Beanshell:Opening a project]]
* [[Beanshell:Limit labels to one per street]]
* [[Beanshell:Scripts for Roadmatcher]]
* [[Beanshell:Create an image layer from a file or URL]]
* [[Beanshell:Find features with repeated points]]
* [[Beanshell:Get the WMS URL that JUMP is using]]
* [[Beanshell:Fill in a JUMP column]]
* [[Beanshell:Setting North Arrow options]]
* [[Beanshell:Setting Scale Bar options]]

Beanshell:Setting North Arrow options

2010-02-05T21:56:48Z

Beckerl: Created page with 'There are many options for the North Arrow Plugin, but no UI to set them. Beanshell to the rescue! == First we must get a reference to the NorthArrowRender == import org.open…'

There are many options for the North Arrow Plugin, but no UI to set them. Beanshell to the rescue!

== First we must get a reference to the NorthArrowRender ==

import org.openjump.core.ui.plugin.view.NorthArrowRenderer;

NorthArrowRenderer renderer = (NorthArrowRenderer) wc.getLayerViewPanel().getRenderingManager().getRenderer(NorthArrowRenderer.CONTENT_ID);

== To set the various styles of North Arrows: ==

renderer.setStyle(1); //the compass rose

renderer.setStyle(2); //the inverted V shape half filled narrower version

renderer.setStyle(3); //the inverted V shape half filled wider version

renderer.setStyle(0); //shaped like a backwards 4 filled with scale bar color

== To set the position that the North Arrow appears in the layer view ==

renderer.setAlignment(0); //BOTTOM_RIGHT = 0, TOP_RIGHT = 1, TOP_LEFT = 2, BOTTOM_LEFT = 3

== Miscellaneous settings ==

renderer.setARROW_SIZE(100);

renderer.setTEXT_FONT_SIZE(18);

renderer.setTEXT_BOTTOM_MARGIN(3);

== A complete example ==

{
NorthArrowRenderer renderer = (NorthArrowRenderer) wc.getLayerViewPanel().getRenderingManager().getRenderer(NorthArrowRenderer.CONTENT_ID);
renderer.setStyle(2);
}

Scripting with BeanShell

2010-02-05T21:28:55Z

Beckerl:

Larry Becker's JUMP Performance Tips

2010-01-05T19:28:08Z

Beckerl:

''The following information was posted by Larry Becker to the JPP Developer's Mailing list and has been posted here by the Sunburned Surveyor for easy reference.''

In the process of doing some software optimizations to the JUMP framework recently, I have learned a few things that can be done by users to increase the speed of JUMP operations, or at least avoid significant slow downs. In order of importance, they are:
# Ensure that you have sufficient free memory by using JUMP's Help->About dialog. When Committed Memory approaches Total Memory, the JVM (Java Virtual Machine) is forced to do constant garbage collection which slows down operations that use lots of temporary memory like redrawing the screen. Unfortunately there is no certain rule for how much is enough, but I would allow at least 10% free. The different versions of JUMP use different methods of allocating memory limits. The SkyJUMP memory limit can be set by increasing the number in the -Xmx512m parameter in the SkyJUMP.ini file in the Jump/bin directory. As a general rule, never increase the number above the amount of physical memory your machine actually has.
# This one is also related to memory usage. If you are doing tasks which involve loading and removing large layers, you will notice that JUMP will not free the memory used by removed layers. The only way to free the memory is to close the task (project). Watch the Committed Memory status and when it approaches the limit, you should consider closing the task and reloading it. Note to developers: unfortunately there doesn't seem to be an easy fix for this as many classes in JUMP hoard local copies of the context which may prevent garbage collection of removed layers (this is speculation on my part).
# Avoid using the labels style on very large layers. Although decimation optimization can reduce redraw times for layers with a large extent, it currently has no effect on text labels. Enabling text labeling on large layers (like burlulc) can cause JUMP to spend minutes rendering tiny invisible text labels. Of course, thanks to JUMP's threaded rendering architecture, you won't be aware that this extra processing is going on, but it will still slow down other processing being done on your computer.
# Consider using the Change Styles Scale tab to avoid displaying a layer at an inappropriate scale. Usually this involves not showing small objects when the zoom level is near the full extent of the layer. Depending on the density of your data, this could be an option for point, label only (scaled), and small feature layers.
# Consider turning off line rendering in the style dialog for polygon layers that don't require borders (such as water layers). It takes just as long for JUMP to render the polygon border as it does the fill, so it can cut the redraw time in half.
# When working with tasks (projects) that have a very large number of layers, and many of the layers are often invisible, consider breaking the task into parts and using the SkyJUMP Merge Task/Archive command to load them into the current task again on an as needed basis. I'm not sure if any of the other JUMP versions have a similar capability, or if OpenJump is going to adopt this feature. The advantage of Merge vs Load Dataset is that layers maintain their style information.
# Another tip to prevent running out of memory when working with a very large number of layers is to make the map window as small as possible. JUMP creates an off screen bitmap the size of the map panel for each visible layer. Imagine opening a hundred picture files at one time and you can see where all the memory goes!

Developing with OpenJUMP

2009-12-15T21:41:07Z

Beckerl:

* [[How to get OpenJUMP source code]]
* [[Developer Documentation and HowTo]]
* "Developer Mailing List":https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
* "Bug Tracker":https://sourceforge.net/tracker/?group_id=118054
* "SVN": http://sourceforge.net/svn/?group_id=118054
* [[Internationalization]]
* [[How to translate OpenJUMP into another language]]
* [[Notes on Speed Improvements on Rendering]]

* [[JTin Google Summer of Code 2008]]
* [[Scripting with BeanShell]]

Developing with OpenJUMP

2009-09-24T20:26:47Z

Beckerl:

* [[How to get OpenJUMP source code]]
* [[Documentation]]
* "Developer Mailing List":https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
* "Bug Tracker":https://sourceforge.net/tracker/?group_id=118054
* "SVN": http://sourceforge.net/svn/?group_id=118054
* [[Internationalization]]
* [[How to translate OpenJUMP into another language]]
* [[Notes on Speed Improvements on Rendering]]

* [[JTin Google Summer of Code 2008]]

JTin Google Summer of Code 2008

2009-09-24T18:43:04Z

Beckerl:

I created this page on the wiki for discussion of the JTin library. This will be a low-level library that allows for the creation and manipulation of TINs. This may be something that we can work on with GeoTools/UDig. In this scenario OpenJUMP and UDig would create their own plug-ins to access the low-level JTin library.

Before serious work begins on the library I think we should make some decisions on the following items:

# How is TIN defined, and how will we represent it in memory? (Note: We aren't talking about the display of a TIN, but rather the model from which a display or view of the TIN might be created.)
# What data input formats will we support? Will we wrap access to these formats in a common interface?
# What data output formats will we support?
# How will we integrate TIN support into OpenJUMP?
# How will we display TINs? Do we want this display to be in the normal Layer View of OpenJUMP? Will this be a 2D display? Will it be a 3D display? Can we support 3D display of a TIN in a separate component to avoid tweaking the existing 2D rendering code?

I will add my comments below. Other interested programmers can add their content also. Then we can make a decision on the best way to proceed.

*TIN Definition*
%{color:blue}The Sunburned Surveyor:% From a land surveying perspective a TIN is defined by three (3) components.

The first component is a collection of points representing the samples of the surface being modeled by the TIN. Each sample site has a horizontal position and a measure of the value being modeled with the surface. (This could be the ground elevation surface or the surface of something completely different, like population)

The second component is a line, either 2D or 3D, that represents the boundaries of the surface being modeled. There must be at least one exterior boundary and there may be one or more interior boundaries. (An interior boundary might be used to exclude a building envelope from an elevation TIN.)

The third component is a set of 3D lines that represent the breaklines of the TIN. TIN lines, or the edges of the triangular faces in the TIN, are not allowed to cross breaklines. Breaklines are a critical component of accurate TIN definition and creation.

I believe that our library should incorporate creation of TINs using all three (3) components, not just the first component, as is typically done in GIS.

Christopher DeMars:% Do we need to include support for both hard and soft breaklines (hard breaklines indicating a change in height along the line like in a road grade)?

%{color:blue}The Sunburned Surveyor:% I'm not really sure what a "soft" breakline would be. What I am talking about would be a hard breakline. It is basically a set of connected TIN lines that can't be crossed by other TIN lines. You would typically create these breaklines along topographic features like ridge tops or valleys.

*TIN Representation*
The Sunburned Surveyor:% I believe that our TIN representation should be made as simple as possible. In my perspective this simplest representation is a set of TIN faces. Each TIN face is defined by three (3) three-dimensional points. I believe we can represent each TIN face by using a JTS Polygon whose nodes have a valid elevation value. Other alternatives are representing each face by a set of raw coordinate values, perhaps as JTS Coordinate objects, or by a set of three (3) LineStrings, with one LineString used to represent each edge of the face. Paul Austin mentioned that representing a face with raw coordinates might be the most efficient method. Whatever method is finally selected, it I think it would be practical to provide methods that allow access to either a JTS Polygon, JTS Point, or JTS LineString representation of the face.

Perhaps the best way to approach this is by encapsulating the common behavior of a TIN face in an interface, and then allowing multiple implementations of this interface using one of the JTS Geometries.

Paul Austin:% Each face is a Triangle which could be modelled as a Triangle object with 3 coordinates. This would be a very efficient data structure and the Triangle object can have methods to return properties of the Triangle such as the circumcentre. There can be methods on the Tin to wrap this Triangle as a Polygon for use in renderring. See CoordinateSequence as the interface that would allow this wrapping.

Christopher DeMars:% Most of the following commentary was inspired by this paper: http://www.cs.unc.edu/%7Eisenburg/papers/ilss-scdt-06.pdf

The paper mentions that another fundamental value to be stored in a TIN for each triangle facet is three links to adjacent facets.

Other aspects that could/should be associated with each TIN face might be precomputed normals and water flow data (like WaterBug, determine where water flowing in the uphill edges exits).

Another big question that needs to be answered is shall we stick with JTS and use a 2.5D model or go full 3D (2.5D surfaces can be projected onto the xy plane without having overlap)? The advantages of 2.5D is that the algorithms are out there and it would mesh well with OpenJUMP. The disadvantage is that we couldnâ€™t model such things as cave structures or mines and the TIN library couldnâ€™t be used for non-GIS 3D applications like medical imaging. The biggest downside to going full 3D is that Delaunay triangulation of 3D surfaces is an open research topic with regards to creating a decently fast implementation. As of this moment, my thoughts are that we should stick with 2.5D, but try to craft the interface such that full 3D code could be plugged in at some future time.

The Sunburned Surveyor:% I agree with Paul. Each TIN face could be stored as three Coordinates. We could then provide methods that return things like a 2D Polygon representation of the triangle, the slope, the aspect, or the normal as suggested by Chris.

However, I don't think we should store topology data in the object representing the actual TIN face. I think this should be stored in a separate data structure or data structures.

Chris wrote: "The disadvantage is that we couldnâ€™t model such things as cave structures or mines and the TIN library couldnâ€™t be used for non-GIS 3D applications like medical imaging."

I didn't even think about that Chris. Those are interesting applications of a TIN library.

Chris wrote: "The biggest downside to going full 3D is that Delaunay triangulation of 3D surfaces is an open research topic with regards to creating a decently fast implementation. As of this moment, my thoughts are that we should stick with 2.5D, but try to craft the interface such that full 3D code could be plugged in at some future time."

Excellent points. I agree with your suggestion. Let's go with 2.5D know, but design the library so that we can plug-in true 3D functionality in the future.

*TIN Input Formats*
Christopher DeMars:% At the very least, we should import DEMs and CSV points are converted into a TIN.

The Sunburned Surveyor:% O.K. - Let's support DEM and CSV in our "alpha" release of the library. Still, we should design an interface that allows access to the three (3) main elements above. That would be (1) 3D points defining the surface, (2) 3D points defining breaklines, and (3) 3d points that define interior and exterior boundaries. We would only require access to a set of 3D points defining the surface. The breaklines and boundaries would be supplemental information that could be using to construct the TIN if available, but which would not be required.

If we take this route I can work on a format for define TINs based on a simple text format. I'd prefer something in YAML, but woudln't be against using XML if there was a lot of support for that.

*TIN Output Formats*
Christopher DeMars:% I see two possibilities. The preferred option IMHO would be to have a streaming architecture where the last stage in the pipeline wrote out the data (triangles, breaklines, borders, waterflow etc) to a PostGIS database. Then the TIN class (or TINDB class) could have a method that returns a subset of the TIN as a new TIN. The new TIN could either be DB backed, or reside only in memory. This would allow us to process, store, and use TINs that are larger than main memory.

Another possible output format would be a raw list of points segregated into a breakline section, border section, and triangle section. This could be either in WKT, WKB, or our own format. In order to save space, markup languages should be avoided. The downside to this is it would be much harder to deal with data sets that dwarf main memory.

The Sunburned Surveyor:% I agree with Chris on some of the main "outputs" our TIN library should support. I think that these should be a representation of the constructed TIN, including TIN faces, breaklines and boundaries. At some point in the future I would hope to see support for contours (as JTS LineStrings so they could be displayed in OpenJUMP) hillshades, and water flow analysis.

Chris mentioned a "streaming" API that allows access to a TIN in a manner that is independent of memory. I believe this is very important. However, I do not believe we should tie the API to any relational database, at least not directly. We should present a streaming API and then allow individual programmers the liberty to choose their implementation. For example, I would personally avoid a relational database and would focus on streaming access to a TIN based on a binary file or series of text files.

*GeoTools/OpenJUMP Collaboration*

*TIN Display Options*

I don't think, at least initially, that we should be concerned with making major modifications to OpenJUMP so that TIN's can be displayed. I think the more simple, and easily obtained solution, would be to focus on exporting data products from a TIN that could be displayed in OpenJUMP. This could be TIN faces represented as JTS Polygons, countour lines represented as JTS LineStrings, and Hillshades represented as JTS Polygons or raster images.

I believe 3D display of TIN files should take place in either [1] a stand alone tool, or [2] in a plug-in specifically designed for display of 3D data. The second option would allow us to write 3D display code that could be used for future extensions in OpenJUMP's functionality. However, I do not think it would be wise to attempt a mash-up of OpenJUMP's current 2D dispaly and a new 3D display. OpenJUMP's current 2D rendering system is quick and capable of producing high-quality map images. Let's not mess with that. Separating display of 3D data into another component will allow us to experiment with and use tools specifically build for 3D data, liek Java OpenGL bindings, without polluting the current (and effective) 2D rendering system.

*Integration of TIN Support In OpenJUMP*

I don't think, at least initially, that we should worry about integrating TINs into OpenJUMP as a special type of feature. Let's concentrate on building TINs and on creating simple output from TINs in the formats OpenJUMP already permits. When we are successful with this goal we can consider adding more built in support for TIN manipulation directly into OpenJUMP via plug-ins.

*Integration of TIN Support In UDig*

h2. Reference

* 2008 Google Summerof Code http://code.google.com/soc/2008/

* TIN (Triangulated irregular network) http://en.wikipedia.org/wiki/Triangulated_irregular_network

* Delaunay triangulation http://en.wikipedia.org/wiki/Delaunay_triangulation

* more

JTin Google Summer of Code 2008

2009-09-24T18:42:15Z

Beckerl: Created page with 'I created this page on the wiki for discussion of the JTin library. This will be a low-level library that allows for the creation and manipulation of TINs. This may be something …'

I created this page on the wiki for discussion of the JTin library. This will be a low-level library that allows for the creation and manipulation of TINs. This may be something that we can work on with GeoTools/UDig. In this scenario OpenJUMP and UDig would create their own plug-ins to access the low-level JTin library.

Before serious work begins on the library I think we should make some decisions on the following items:

# How is TIN defined, and how will we represent it in memory? (Note: We aren't talking about the display of a TIN, but rather the model from which a display or view of the TIN might be created.)
# What data input formats will we support? Will we wrap access to these formats in a common interface?
# What data output formats will we support?
# How will we integrate TIN support into OpenJUMP?
# How will we display TINs? Do we want this display to be in the normal Layer View of OpenJUMP? Will this be a 2D display? Will it be a 3D display? Can we support 3D display of a TIN in a separate component to avoid tweaking the existing 2D rendering code?

I will add my comments below. Other interested programmers can add their content also. Then we can make a decision on the best way to proceed.

*TIN Definition*
%{color:blue}The Sunburned Surveyor:% From a land surveying perspective a TIN is defined by three (3) components.

The first component is a collection of points representing the samples of the surface being modeled by the TIN. Each sample site has a horizontal position and a measure of the value being modeled with the surface. (This could be the ground elevation surface or the surface of something completely different, like population)

The second component is a line, either 2D or 3D, that represents the boundaries of the surface being modeled. There must be at least one exterior boundary and there may be one or more interior boundaries. (An interior boundary might be used to exclude a building envelope from an elevation TIN.)

The third component is a set of 3D lines that represent the breaklines of the TIN. TIN lines, or the edges of the triangular faces in the TIN, are not allowed to cross breaklines. Breaklines are a critical component of accurate TIN definition and creation.

I believe that our library should incorporate creation of TINs using all three (3) components, not just the first component, as is typically done in GIS.

%{color:green}Christopher DeMars:% Do we need to include support for both hard and soft breaklines (hard breaklines indicating a change in height along the line like in a road grade)?

%{color:blue}The Sunburned Surveyor:% I'm not really sure what a "soft" breakline would be. What I am talking about would be a hard breakline. It is basically a set of connected TIN lines that can't be crossed by other TIN lines. You would typically create these breaklines along topographic features like ridge tops or valleys.

*TIN Representation*
%{color:blue}The Sunburned Surveyor:% I believe that our TIN representation should be made as simple as possible. In my perspective this simplest representation is a set of TIN faces. Each TIN face is defined by three (3) three-dimensional points. I believe we can represent each TIN face by using a JTS Polygon whose nodes have a valid elevation value. Other alternatives are representing each face by a set of raw coordinate values, perhaps as JTS Coordinate objects, or by a set of three (3) LineStrings, with one LineString used to represent each edge of the face. Paul Austin mentioned that representing a face with raw coordinates might be the most efficient method. Whatever method is finally selected, it I think it would be practical to provide methods that allow access to either a JTS Polygon, JTS Point, or JTS LineString representation of the face.

Perhaps the best way to approach this is by encapsulating the common behavior of a TIN face in an interface, and then allowing multiple implementations of this interface using one of the JTS Geometries.

%{color:blue}Paul Austin:% Each face is a Triangle which could be modelled as a Triangle object with 3 coordinates. This would be a very efficient data structure and the Triangle object can have methods to return properties of the Triangle such as the circumcentre. There can be methods on the Tin to wrap this Triangle as a Polygon for use in renderring. See CoordinateSequence as the interface that would allow this wrapping.

%{color:green}Christopher DeMars:% Most of the following commentary was inspired by this paper: http://www.cs.unc.edu/%7Eisenburg/papers/ilss-scdt-06.pdf

The paper mentions that another fundamental value to be stored in a TIN for each triangle facet is three links to adjacent facets.

Other aspects that could/should be associated with each TIN face might be precomputed normals and water flow data (like WaterBug, determine where water flowing in the uphill edges exits).

Another big question that needs to be answered is shall we stick with JTS and use a 2.5D model or go full 3D (2.5D surfaces can be projected onto the xy plane without having overlap)? The advantages of 2.5D is that the algorithms are out there and it would mesh well with OpenJUMP. The disadvantage is that we couldnâ€™t model such things as cave structures or mines and the TIN library couldnâ€™t be used for non-GIS 3D applications like medical imaging. The biggest downside to going full 3D is that Delaunay triangulation of 3D surfaces is an open research topic with regards to creating a decently fast implementation. As of this moment, my thoughts are that we should stick with 2.5D, but try to craft the interface such that full 3D code could be plugged in at some future time.

%{color:blue}The Sunburned Surveyor:% I agree with Paul. Each TIN face could be stored as three Coordinates. We could then provide methods that return things like a 2D Polygon representation of the triangle, the slope, the aspect, or the normal as suggested by Chris.

However, I don't think we should store topology data in the object representing the actual TIN face. I think this should be stored in a separate data structure or data structures.

Chris wrote: "The disadvantage is that we couldnâ€™t model such things as cave structures or mines and the TIN library couldnâ€™t be used for non-GIS 3D applications like medical imaging."

I didn't even think about that Chris. Those are interesting applications of a TIN library.

Chris wrote: "The biggest downside to going full 3D is that Delaunay triangulation of 3D surfaces is an open research topic with regards to creating a decently fast implementation. As of this moment, my thoughts are that we should stick with 2.5D, but try to craft the interface such that full 3D code could be plugged in at some future time."

Excellent points. I agree with your suggestion. Let's go with 2.5D know, but design the library so that we can plug-in true 3D functionality in the future.

*TIN Input Formats*
%{color:green}Christopher DeMars:% At the very least, we should import DEMs and CSV points are converted into a TIN.

%{color:blue}The Sunburned Surveyor:% O.K. - Let's support DEM and CSV in our "alpha" release of the library. Still, we should design an interface that allows access to the three (3) main elements above. That would be (1) 3D points defining the surface, (2) 3D points defining breaklines, and (3) 3d points that define interior and exterior boundaries. We would only require access to a set of 3D points defining the surface. The breaklines and boundaries would be supplemental information that could be using to construct the TIN if available, but which would not be required.

If we take this route I can work on a format for define TINs based on a simple text format. I'd prefer something in YAML, but woudln't be against using XML if there was a lot of support for that.

*TIN Output Formats*
%{color:green}Christopher DeMars:% I see two possibilities. The preferred option IMHO would be to have a streaming architecture where the last stage in the pipeline wrote out the data (triangles, breaklines, borders, waterflow etc) to a PostGIS database. Then the TIN class (or TINDB class) could have a method that returns a subset of the TIN as a new TIN. The new TIN could either be DB backed, or reside only in memory. This would allow us to process, store, and use TINs that are larger than main memory.

Another possible output format would be a raw list of points segregated into a breakline section, border section, and triangle section. This could be either in WKT, WKB, or our own format. In order to save space, markup languages should be avoided. The downside to this is it would be much harder to deal with data sets that dwarf main memory.

%{color:blue}The Sunburned Surveyor:% I agree with Chris on some of the main "outputs" our TIN library should support. I think that these should be a representation of the constructed TIN, including TIN faces, breaklines and boundaries. At some point in the future I would hope to see support for contours (as JTS LineStrings so they could be displayed in OpenJUMP) hillshades, and water flow analysis.

Chris mentioned a "streaming" API that allows access to a TIN in a manner that is independent of memory. I believe this is very important. However, I do not believe we should tie the API to any relational database, at least not directly. We should present a streaming API and then allow individual programmers the liberty to choose their implementation. For example, I would personally avoid a relational database and would focus on streaming access to a TIN based on a binary file or series of text files.

*GeoTools/OpenJUMP Collaboration*

*TIN Display Options*

I don't think, at least initially, that we should be concerned with making major modifications to OpenJUMP so that TIN's can be displayed. I think the more simple, and easily obtained solution, would be to focus on exporting data products from a TIN that could be displayed in OpenJUMP. This could be TIN faces represented as JTS Polygons, countour lines represented as JTS LineStrings, and Hillshades represented as JTS Polygons or raster images.

I believe 3D display of TIN files should take place in either [1] a stand alone tool, or [2] in a plug-in specifically designed for display of 3D data. The second option would allow us to write 3D display code that could be used for future extensions in OpenJUMP's functionality. However, I do not think it would be wise to attempt a mash-up of OpenJUMP's current 2D dispaly and a new 3D display. OpenJUMP's current 2D rendering system is quick and capable of producing high-quality map images. Let's not mess with that. Separating display of 3D data into another component will allow us to experiment with and use tools specifically build for 3D data, liek Java OpenGL bindings, without polluting the current (and effective) 2D rendering system.

*Integration of TIN Support In OpenJUMP*

I don't think, at least initially, that we should worry about integrating TINs into OpenJUMP as a special type of feature. Let's concentrate on building TINs and on creating simple output from TINs in the formats OpenJUMP already permits. When we are successful with this goal we can consider adding more built in support for TIN manipulation directly into OpenJUMP via plug-ins.

*Integration of TIN Support In UDig*

h2. Reference

* 2008 Google Summerof Code http://code.google.com/soc/2008/

* TIN (Triangulated irregular network) http://en.wikipedia.org/wiki/Triangulated_irregular_network

* Delaunay triangulation http://en.wikipedia.org/wiki/Delaunay_triangulation

* more

Notes on Speed Improvements on Rendering

2009-09-24T18:41:21Z

Beckerl: Created page with 'note: for further info see the emails with subject _OJ extreme slowness_ on Jump User List around 28/29 November 2006 A big thanx to Larry and Bob for investing the time! sstein …'

note: for further info see the emails with subject _OJ extreme slowness_ on Jump User List around 28/29 November 2006
A big thanx to Larry and Bob for investing the time!
sstein

*Larry Becker wrote* (30 Nov. 2006):
OK, let's see if we can't put this issue to rest. The RenderingManager has a 1 second repaint timer that allows the GUI to appear responsive by updating the screen every second during long operations like dataset loading. The code is:
<pre>
<code>

private Timer repaintTimer = new Timer(1000, new ActionListener() {
public void actionPerformed(ActionEvent e) {
for (Iterator i = contentIDToRendererMap.values().iterator(); i
.hasNext();) {
Renderer renderer = (Renderer) i.next();
if (renderer.isRendering()) {
repaintPanel();
return;
}
}

repaintTimer.stop();
repaintPanel();
}
});
</code>
</pre>

Notice the final repaintPanel() invocation. This is what is triggering the second paint that Fco is seeing. I have commented out the final repaintPanel() and observed no ill effects on correct rendering, however it had no positive effects on render times either. I recommend leaving it as is for belt-AND-suspenders paranoia.

Robert and I have done fairly extensive analysis of JUMP's rendering pipeline and have not found anything that can be significantly improved. We have done experiments with blocking vs. non-blocking renderers and found no improvement. Robert tried rendering more features in each synchronized draw invocation (as Jon's comment recommended) and found no improvement in speed. I want to emphasize that all of these mods have decreased the responsiveness of the GUI without noticeably increasing drawing speed.

In conclusion, the results of our benchmarks, analysis, and experiments show that JUMP's rendering is one of the best compromises of quality, responsiveness, and speed that I have ever seen in an application.

One final word: late tests of JUMP 1.2 of redraw of the 48MB burlulc.shp file (New Jersey) dataset have deteriorated to 20 seconds from 11 in the previous version. I an unaware of any reason for this slowdown, except for perhaps the addition of the new Imaging layer type since OpenJUMP and SkyJUMP have implemented most of the JUMP 1.2 improvements except Imaging and do not experience any slowdown.

regards,
Larry Becker
ISA

How to translate OpenJUMP into another language

2009-09-24T18:40:31Z

Beckerl: Created page with ' A - The steps on how to translate OpenJUMP This in an *example for* translation into *Brazilian Portugese*. People interests in creating a new language file my read part B (bel…'

A - The steps on how to translate OpenJUMP

This in an *example for* translation into *Brazilian Portugese*.
People interests in creating a new language file my read part B (below) as well

* 1) download the last nightly built:
http://jonaquino.textdriven.com/openjump_nightly_builds/
* 2) unpack it
* 3) if you work on Windows:
** set in the file YOUR_openjump_folder\bin\openjump.bat
the i18n option to portugese language in the "start javaw" line:
** eg.
start javaw -Dlog4j.configuration=file:./log4j.xml -Xms256M -Xmx256M -cp
%CLASSPATH% com.vividsolutions.jump.workbench.JUMPWorkbench -properties
workbench-properties.xml -i18n pt_BR -plug-in-directory %LIB%/ext
** otherwise modify the appropriate .sh file
* 4) go to the file:
YOUR_openjump_folder\lib\jump-workbench-2007XXXX-XXXX.jar (where xxx are
nightly built specific number)
* 5) for safety reasons make a copy of the file to some other place
* 6) rename the .jar file to .zip
* 7) unpack it somewhere
* 8) look in the unpacked files for folder called "language" and a file
called "jump_pt_BR.properties"
* 9) open the file with your favorite editor and translate the strings:
** you will see that on left side is an identifier string while on the
side of the "=" equal sign is the translated text
** a hint: new strings have a date line just before like [sstein 7 march 2007]
* 10) after you have translated, safe the jump_pt_BR.properties file

==========
note: the following steps are useful if you want to check your
translation in OpenJUMP;

* 11) pack all the stuff of the previously extracted zip file to a new .zip which has the same name as the old
* 12) rename the just packed file .zip to .jar
* 13) copy it in the same location as the old .jar (means the \lib\ folder)
* 14) start openjump with the openjump.bat file and check your translation

=========== if you dont want to test:
* 15) if you finished your translation send me the jump_pt_BR.properties file
(sstein@geo....) and i will add it to our sourcecode repository.

After adding it, the nightly built of the next day should include your Portugese translation.
I hope that is detailed enough :o)
If questions appear please don't hesitate to contact me (Stefan/sstein)

B - On new translations

* please simply make a copy of the file jump_en.properties file and
rename the copy to your language abbreviation (e.g. the swedish one should be like: jump_se.properties)
* translate everything
* put it as additional file in the zip as describe above

C - Useful tools

* some of the developers use the prb-editor for translatiion https://prbeditor.dev.java.net/

Internationalization

2009-09-24T18:39:06Z

Beckerl: Created page with 'This page will offer information and tips on internationalization to developers working on OpenJUMP or other projects at the JPP. Internationalization is an important part of Ope…'

This page will offer information and tips on internationalization to developers working on OpenJUMP or other projects at the JPP. Internationalization is an important part of OpenJUMP which is used around the world in many different languages.

*Language 2 Developer Registry*
This is a simple registry that shows which developers are working on OpenJUMP or other JPP projects in specific language groups. This will help developers find developers that are working in a language they understand, and will identify those that can assist in language specific translation and internationlization issues. You can contact most of these developers on the "JPP Development Mailing List":http://lists.sourceforge.net/lists/listinfo/jump-pilot-devel .

*_English_*
The Sunburned Surveyor

*_Spanish_*
Nacho Uve, Steve Tanner, Fco Lavin

*_French_*
Michael Michaud, Steve Tanner, Erwan Bocher

*_German_*
Stefan Steiniger, Johannes Metzler, Florian Rengers

*_Brazilian Portugese_*
Cristiano Almeida

*_Finnish_*
Jukka Rahkonen

*_Italian_*
Giuseppe Aruta

*_Japanese_*
Hisaji Ono

*_Hungarian_*
Istvan Stefan and Zoltan Siki

*_Czech_*
N.N.

<hr />

*Lists of GIS-Term difficult to translate*

* [[Portugese Word List]]
* [[German Word List]]
* [[Spanish Word List]]

Documentation

2009-09-24T18:37:39Z

Beckerl:

This page gives access to documentation for *users* and *developers* (pls. scroll down).

<hr />

A - Documentation for users !http://static.flickr.com/39/110072620_882b70fee7.jpg?v=0!

<hr />

On-Line Documentation (English)

* !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/icons/book_open.png! \OpenJUMP "User Guide":http://openjump.org/wiki/show/Index

* !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/icons/book_open.png! "OpenJUMP on MacOSX":http://openjump.org/wiki/revision/ComparingOpenJump?rev=19 with a comparison between \OpenJUMP,uDig and QGIS by Eric Jarvies

* !http://static.flickr.com/31/99200779_79abbaccb5_o.png! [[FAQ]] and !http://static.flickr.com/31/99200779_79abbaccb5_o.png! "FAQ":http://openjump.org/wiki/show/Known+Issues+on+MacOSX for Mac OX

Download (PDF)

* An English "OpenJUMP 1.3 Tutorial":http://sourceforge.net/projects/jump-pilot/files/ by Stefan Steiniger and Michael Michaud for users with a basic GIS knowledge that was held at "OGRS 2009":http://www.ogrs2009.org (data are unfortunately not free) !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif!
* A German introductory "OpenJUMP 1.2F Tutorial":https://sourceforge.net/project/downloading.php?group_id=118054&use_mirror=garr&filename=OpenJUMP12_German_Tutorial_sz.pdf&72973093 by Uwe Dalluege with sample data !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/de.gif!
* An English "OpenJUMP 1.1 Tutorial":http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/j/ju/jump-pilot/OpenJUMP1.0.1_Tutorial_englishBeta.pdf by Uwe Dalluege !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif!
* A German "PostGIS Tutorial":http://openjump.org/PostGIS_Tutorial.pdf by Uwe Dalluege !http://static.flickr.com/24/99192265_912fc9665e_o.gif!
* An English "pseudo-exercise":http://jump-pilot.sourceforge.net/download/mock-ex4jump.zip by Ravi with the topic: Where to locate a nuclear power plant? It introduces \OpenJUMPs basic analysis functions.
* Another English "pseudo-exercise":http://jump-pilot.sourceforge.net/download/mockex_mineral_targeting_v2.zip for \OpenJUMP 1.3 by Ravi on mineral targeting. It introduces into \OpenJUMP editing, query and analyis function as well as into working with \PostGIS.

* *Original* VIVID Solutions JUMP 1.1 User Guide - !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif! "English":http://www.vividsolutions.com/jump/bin/JUMP%20User%20Guide.pdf, !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/es.gif! "Spanish":http://jump-pilot.svn.sourceforge.net/viewvc/*checkout*/jump-pilot/core/trunk/docs/manuals-es/JUMP-Doc-es-GuiaUsuario.pdf

* JUMP 1.1 / \OpenJUMP Tutorials in other languages:
** !http://static.flickr.com/32/99192264_28e14852b0_o.gif! "Portuguese User Guide":http://www.archive.org/download/OpenJUMP_Users_Guid_pt_br/ManualOpenJUMP.pdf by Flavia Coelho Couto JoÃ£o Batista Brito and Ezequias Rodrigues da Rocha
** !http://static.flickr.com/32/99192264_28e14852b0_o.gif! "Presentation":http://www.archive.org/download/OpenJUMP_presentation_ppt_pt_br/PalestraLACFee2005OpenJUMP.ppt, by Ezequias R. da Rocha
** !http://static.flickr.com/47/116386051_725a6b5470.jpg?v=0! "Italian User Guide":http://geomatica.como.polimi.it/corsi/sw_gis/OpenJUMP-CAN-CC.pdf by Diego Magni
** !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/jp.gif! "User Guide for Field Work GIS Station powered by \OpenJUMP in Japanese ":http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fgiswin.geo.tsukuba.ac.jp%2Fteacher%2Fmurayama%2Ffieldgis_station%2Fmanual%2Fmanual.pdf&ei=yVnhR57wGpb4nQOM4OmjCA&usg=AFQjCNEhFckYIYd9Vowo7mpsk4_8TaywcQ&sig2=-lP0jfD3iRp_k1Z4-u3I9Q by Yuji Murayama, Hisaji Ono
** !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif! OpenJump Workshop for Foss4G 2006 by Erwan Brocher - this tutorial has been updated for \OpenJUMP 1.3 and presented at OGRS 2009 (see above)

* "Other original JUMP documentation":http://www.vividsolutions.com/jump/doc.htm (a wee bit old) !http://static.flickr.com/30/99196199_5d9b12aca7_o.gif!

Other on-line documentation

* [[Plugins]] - \PlugIn's by others - will probably not integrated into \OpenJump
* [[Experiences developing OpenJUMP]] - A paper prepared for the MILES project (Managing Information for Local Environment in Sri Lanka)
* [[Scripting with BeanShell]]
* [[Tips]]
* [[OpenJump Configuration]]
* [[Printing in high-resolution]]
* [[TFW (World File) Format]]
* [[Drawing an on-screen ornament]]
* [[Loading GPS data]]
* [[Shortcut Keys 1-pager]]
* [[Sample data]]
* [[OpenJump with Wallpaper :-O]]
* [[Portable OpenJump]]
* What is GIS? - GIS Basics by the \OpenContent "GITTA elearning project":http://www.gitta.info/website/en/html/index.html

<hr/>

B - Documentation for developers !http://static.flickr.com/39/110072620_882b70fee7.jpg?v=0!

<hr />

* "Jump Developers Guide":http://www.vividsolutions.com/jump/bin/JUMP%20Developer%20Guide.pdf !http://static.flickr.com/24/99217499_2d71c8c43a_o.png!
* [[Devel FAQ]]
* *Basics*
** [[How to run OpenJUMP in Eclipse]]
** [[How to make your own OpenJUMP built]]
** "OpenJUMP javadoc":http://jump-pilot.sourceforge.net/javadoc/openjump_javadoc/ , "JTS javadoc":http://tsusiatsoftware.net/jts/javadoc/index.html
** [[OpenJUMP programming Guideline]]
* *Making Your Own Plugins*
** [[The difference of PlugIn and Extension and Registry]]
** [[How to use and make own Plugins]]
** Example \PlugIns:
*** [[How to display customer xyz data from a file]]
*** [[Example Plugin For Buffering Features in a Layer]]
** [[How to use i18n Internationalization]]
** [[Implementing Undo]]
** [[Adding A Toolbar Button]]
** [[Implementing cursortools]]
** [[Converting a CursorTool to a PlugIn]]
** [[Extending a FeatureCollection by Adding new Attributes]]
* [[Tips and Tricks around the Java Topology Suite]]
* [[Notes On OpenJUMP's Rendering System]]
* [[Notes on TaskFrames]]
* [[Notes on the Display of AttributeTables]]
* [[Using JUMP Libraries in an External Application]].
* Adding support for new data formats:
** [[How to write a new driver]] (Spring 2007)
** [[HOWTO Create an Open Wizard]] (Since \OpenJUMP Version 1.2)
** Some additional notes on adding support for a new file format: [[File DataSource Notes]]
** [[Working with GML]]
* *Other*
** "How to Translate \OpenJUMP into another language":http://openjump.org/wiki/show/How+to+translate+in+a+new+language

<hr/>

C - Projects where \OpenJUMP can give its contribution

<hr />

* "OSGeo Cartographic Library":http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library#Interested_people

<hr />

* [[GIS Terminology]]

Documentation

2009-09-24T18:36:28Z

Beckerl: Created page with 'This page gives access to documentation for *users* and *developers* (pls. scroll down). <hr /> h2()=[no]. A - Documentation for users !http://static.flickr.com/39/110072620_8…'

This page gives access to documentation for *users* and *developers* (pls. scroll down).

<hr />

h2()=[no]. A - Documentation for users !http://static.flickr.com/39/110072620_882b70fee7.jpg?v=0!

<hr />

h3()=[no]{color:black}. On-Line Documentation (English)

* !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/icons/book_open.png! \OpenJUMP "User Guide":http://openjump.org/wiki/show/Index

* !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/icons/book_open.png! "OpenJUMP on MacOSX":http://openjump.org/wiki/revision/ComparingOpenJump?rev=19 with a comparison between \OpenJUMP,uDig and QGIS by Eric Jarvies

* !http://static.flickr.com/31/99200779_79abbaccb5_o.png! [[FAQ]] and !http://static.flickr.com/31/99200779_79abbaccb5_o.png! "FAQ":http://openjump.org/wiki/show/Known+Issues+on+MacOSX for Mac OX

h3()=[no]{color:black}. Download (PDF)

* An English "OpenJUMP 1.3 Tutorial":http://sourceforge.net/projects/jump-pilot/files/ by Stefan Steiniger and Michael Michaud for users with a basic GIS knowledge that was held at "OGRS 2009":http://www.ogrs2009.org (data are unfortunately not free) !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif!
* A German introductory "OpenJUMP 1.2F Tutorial":https://sourceforge.net/project/downloading.php?group_id=118054&use_mirror=garr&filename=OpenJUMP12_German_Tutorial_sz.pdf&72973093 by Uwe Dalluege with sample data !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/de.gif!
* An English "OpenJUMP 1.1 Tutorial":http://www.mirrorservice.org/sites/download.sourceforge.net/pub/sourceforge/j/ju/jump-pilot/OpenJUMP1.0.1_Tutorial_englishBeta.pdf by Uwe Dalluege !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif!
* A German "PostGIS Tutorial":http://openjump.org/PostGIS_Tutorial.pdf by Uwe Dalluege !http://static.flickr.com/24/99192265_912fc9665e_o.gif!
* An English "pseudo-exercise":http://jump-pilot.sourceforge.net/download/mock-ex4jump.zip by Ravi with the topic: Where to locate a nuclear power plant? It introduces \OpenJUMPs basic analysis functions.
* Another English "pseudo-exercise":http://jump-pilot.sourceforge.net/download/mockex_mineral_targeting_v2.zip for \OpenJUMP 1.3 by Ravi on mineral targeting. It introduces into \OpenJUMP editing, query and analyis function as well as into working with \PostGIS.

* *Original* VIVID Solutions JUMP 1.1 User Guide - !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif! "English":http://www.vividsolutions.com/jump/bin/JUMP%20User%20Guide.pdf, !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/es.gif! "Spanish":http://jump-pilot.svn.sourceforge.net/viewvc/*checkout*/jump-pilot/core/trunk/docs/manuals-es/JUMP-Doc-es-GuiaUsuario.pdf

* JUMP 1.1 / \OpenJUMP Tutorials in other languages:
** !http://static.flickr.com/32/99192264_28e14852b0_o.gif! "Portuguese User Guide":http://www.archive.org/download/OpenJUMP_Users_Guid_pt_br/ManualOpenJUMP.pdf by Flavia Coelho Couto JoÃ£o Batista Brito and Ezequias Rodrigues da Rocha
** !http://static.flickr.com/32/99192264_28e14852b0_o.gif! "Presentation":http://www.archive.org/download/OpenJUMP_presentation_ppt_pt_br/PalestraLACFee2005OpenJUMP.ppt, by Ezequias R. da Rocha
** !http://static.flickr.com/47/116386051_725a6b5470.jpg?v=0! "Italian User Guide":http://geomatica.como.polimi.it/corsi/sw_gis/OpenJUMP-CAN-CC.pdf by Diego Magni
** !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/jp.gif! "User Guide for Field Work GIS Station powered by \OpenJUMP in Japanese ":http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fgiswin.geo.tsukuba.ac.jp%2Fteacher%2Fmurayama%2Ffieldgis_station%2Fmanual%2Fmanual.pdf&ei=yVnhR57wGpb4nQOM4OmjCA&usg=AFQjCNEhFckYIYd9Vowo7mpsk4_8TaywcQ&sig2=-lP0jfD3iRp_k1Z4-u3I9Q by Yuji Murayama, Hisaji Ono
** !http://jump-pilot.sourceforge.net/wikiimages//wikisymbolsandflags/flags/gif/gb.gif! OpenJump Workshop for Foss4G 2006 by Erwan Brocher - this tutorial has been updated for \OpenJUMP 1.3 and presented at OGRS 2009 (see above)

* "Other original JUMP documentation":http://www.vividsolutions.com/jump/doc.htm (a wee bit old) !http://static.flickr.com/30/99196199_5d9b12aca7_o.gif!

h3()=[no]{color:black}. Other on-line documentation

* [[Plugins]] - \PlugIn's by others - will probably not integrated into \OpenJump
* [[Experiences developing OpenJUMP]] - A paper prepared for the MILES project (Managing Information for Local Environment in Sri Lanka)
* [[Scripting with BeanShell]]
* [[Tips]]
* [[OpenJump Configuration]]
* [[Printing in high-resolution]]
* [[TFW (World File) Format]]
* [[Drawing an on-screen ornament]]
* [[Loading GPS data]]
* [[Shortcut Keys 1-pager]]
* [[Sample data]]
* [[OpenJump with Wallpaper :-O]]
* [[Portable OpenJump]]
* What is GIS? - GIS Basics by the \OpenContent "GITTA elearning project":http://www.gitta.info/website/en/html/index.html

<hr/>

h2()=[no]. B - Documentation for developers !http://static.flickr.com/39/110072620_882b70fee7.jpg?v=0!

<hr />

* "Jump Developers Guide":http://www.vividsolutions.com/jump/bin/JUMP%20Developer%20Guide.pdf !http://static.flickr.com/24/99217499_2d71c8c43a_o.png!
* [[Devel FAQ]]
* *Basics*
** [[How to run OpenJUMP in Eclipse]]
** [[How to make your own OpenJUMP built]]
** "OpenJUMP javadoc":http://jump-pilot.sourceforge.net/javadoc/openjump_javadoc/ , "JTS javadoc":http://tsusiatsoftware.net/jts/javadoc/index.html
** [[OpenJUMP programming Guideline]]
* *Making Your Own Plugins*
** [[The difference of PlugIn and Extension and Registry]]
** [[How to use and make own Plugins]]
** Example \PlugIns:
*** [[How to display customer xyz data from a file]]
*** [[Example Plugin For Buffering Features in a Layer]]
** [[How to use i18n Internationalization]]
** [[Implementing Undo]]
** [[Adding A Toolbar Button]]
** [[Implementing cursortools]]
** [[Converting a CursorTool to a PlugIn]]
** [[Extending a FeatureCollection by Adding new Attributes]]
* [[Tips and Tricks around the Java Topology Suite]]
* [[Notes On OpenJUMP's Rendering System]]
* [[Notes on TaskFrames]]
* [[Notes on the Display of AttributeTables]]
* [[Using JUMP Libraries in an External Application]].
* Adding support for new data formats:
** [[How to write a new driver]] (Spring 2007)
** [[HOWTO Create an Open Wizard]] (Since \OpenJUMP Version 1.2)
** Some additional notes on adding support for a new file format: [[File DataSource Notes]]
** [[Working with GML]]
* *Other*
** "How to Translate \OpenJUMP into another language":http://openjump.org/wiki/show/How+to+translate+in+a+new+language

<hr/>

h2()=[no]. C - Projects where \OpenJUMP can give its contribution

<hr />

* "OSGeo Cartographic Library":http://wiki.osgeo.org/wiki/OSGeo_Cartographic_Library#Interested_people

<hr />

* [[GIS Terminology]]

Developing with OpenJUMP

2009-09-24T18:33:01Z

Beckerl:

* [[How to get OpenJUMP source code]]
* [[Documentation]]
* "Developer Mailing List":https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
* "Bug Tracker":https://sourceforge.net/tracker/?group_id=118054
* "SVN": http://sourceforge.net/svn/?group_id=118054 !http://static.flickr.com/40/116458104_c6bc7d63ce.jpg?v=0!
* [[Internationalization]]
* [[How to translate OpenJUMP into another language]]
* [[Notes on Speed Improvements on Rendering]]

* [[JTin Google Summer of Code 2008]]

Developing with OpenJUMP

2009-09-24T18:20:10Z

Beckerl:

* [https://sourceforge.net/apps/mediawiki/jump-pilot/How+to+get+OpenJUMP+source+code.html How to get OpenJUMP source code]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/Documentation.html Documentation]
* [https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel Developer Mailing List]
* [https://sourceforge.net/tracker/?group_id=118054 Bug Tracker]
* “SVN”: http://sourceforge.net/svn/?group_id=118054 [[Image:116458104_c6bc7d63ce.jpg]]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/Internationalization.html Internationalization]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/How+to+translate+OpenJUMP+into+another+language.html How to translate OpenJUMP into another language]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/Notes+on+Speed+Improvements+on+Rendering.html Notes on Speed Improvements on Rendering]

* [https://sourceforge.net/apps/mediawiki/jump-pilot/JTin+Google+Summer+of+Code+2008.html JTin Google Summer of Code 2008]

<div class="byline"> Revised on September 14, 2009 18:51:14 by <span class="newWikiWord">angela12jones@yahoo.com</span></div>

Developing with OpenJUMP

2009-09-24T18:18:45Z

Beckerl: Created page with '* [https://sourceforge.net/apps/mediawiki/jump-pilot/How+to+get+OpenJUMP+source+code.html How to get OpenJUMP source code] * [https://sourceforge.net/apps/mediawiki/jump-pilot/Do…'

* [https://sourceforge.net/apps/mediawiki/jump-pilot/How+to+get+OpenJUMP+source+code.html How to get OpenJUMP source code]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/Documentation.html Documentation]
* [https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel Developer Mailing List]
* [https://sourceforge.net/tracker/?group_id=118054 Bug Tracker]
* “SVN”: http://sourceforge.net/svn/?group_id=118054 [[Image:116458104_c6bc7d63ce.jpg]]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/Internationalization.html Internationalization]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/How+to+translate+OpenJUMP+into+another+language.html How to translate OpenJUMP into another language]
* [https://sourceforge.net/apps/mediawiki/jump-pilot/Notes+on+Speed+Improvements+on+Rendering.html Notes on Speed Improvements on Rendering]
* [http://www.essayontime.com | Essay]

* [https://sourceforge.net/apps/mediawiki/jump-pilot/JTin+Google+Summer+of+Code+2008.html JTin Google Summer of Code 2008]

<div class="byline"> Revised on September 14, 2009 18:51:14 by <span class="newWikiWord">angela12jones@yahoo.com</span></div>