Hi.
What might happen if it is the geometry that is null in the database?
It is rather common situation sometimes, it is quite possible that we
know for example parcel attributes beforehand and we should just
digitise the borders afterwards.
The DB Query plugin (or should those plugins be call
>From the point of view of BasicFeature, there is no distinction between the
geometry and any other attribute. All modifications are still funneled
through setAttribute(). For example the setGeometry() code in
AbstractBasicFeature is:
public void setGeometry(Geometry geometry) {
setA
I believe Larry is correct. A database "null" and a null Java
reference are not the same thing. I'm not absolutely sure about this,
but I bet one of our database wizards could confirm.
The Sunburned Surveyor
On Wed, Apr 29, 2009 at 7:44 AM, Larry Becker wrote:
> >From the point of view of BasicF
No, I didn't do any direct comparisons with Shewchuk's (rightly famous)
Triangle library. It would be interesting to know which is faster. I
will not be surprised if his code is more robust - he has a deeper
knowledge and far more experience with triangulation robustness than I do.
So test aw
I'm writing a PNEZD text file importer, and I'd like to have it
properly integrate with the OpenJUMP GUI. I'd also like to modify my
GPX plug-in so it does the same thing. Basically, I want the user to
be able to import these files through the open file menu command.
Does anyone know if this wiki
I'm working on some tweaks for my own build of OpenJUMP. I'd like to
store unit and coordinate system information for tasks. This will
allow me to get rid of those annoying metric units on the zoom bar
when I'm working in data in the Imperial system of the United States,
or when I am working with d
To those that are interested in the upcoming JTS triangulation API, a
question:
What type of input and output structures would you find useful?
Currently I'm developing the following:
INPUT:
- Geometry (from which the site/vertex coordinates are extracted)
- Collection of Coordinates
OUTPUT:
-
Martin,
This is just a suggestion, but Christopher has already done some great
work on file formats for TIN information. Maybe JTS could use that?
My typical surveying workflow is something like this:
Input:
- 3D Points (Point Number, Northing, Easting, Elevation, Description)
- Breaklines (3D P
The JTS API per se will just be focussed on computing the raw TIN edges
and triangles. Any further information (such as contour lines,
slope/aspect etc) are outside the scope of JTS, but can be built fairly
easily on top of the functionality the JTS API provides.
So this won't be replacing th
Hi,
I made a try with native OJ database tools after updating some geometries to
null.
1) "Add - Datastore layer" with WHERE clause selects nothing
2) "Layer - Run DB query" gives an error
Result was not surprising, I were more surprised some time ago when I notised
that the DB Query extension
This makes sense. JTS would be providing a triangulation algorithm to
JTin, and nothing more. In that case, we'd want to ask Christopher
what type of input and output the JTin code expects from its pluggable
TIN creators.
SS
On Wed, Apr 29, 2009 at 10:28 AM, Martin Davis wrote:
> The JTS API per
Stefan,
I have modified the batch script that installs the Super Select
plug-in to automatically install the plug-in if OpenJUMP is located at
c:\Program Files\openjump-1.3.
If the path to the OpenJUMP folder is different, one would have to
edit the batch script.
I also realized the jodd.jar lib
Yup, exactly so.
Sunburned Surveyor wrote:
> This makes sense. JTS would be providing a triangulation algorithm to
> JTin, and nothing more. In that case, we'd want to ask Christopher
> what type of input and output the JTin code expects from its pluggable
> TIN creators.
>
> SS
>
> On Wed, Apr 29
Hei Martin,
mhm.. need to think about it for a while.
input for my work can bot only be corners of a geometry, but the
centroid of a geometry as well - if I want to triangulate for instance
buildings. However, this would only require to derive the centroids as
an additional step. Import here i
For input, it would be nice to be able to give a collection of coordinates (or
Points for that matter) and an optional collection of lines to use for the
constrained algorithm.
For output, it would be nice to have some way to get a raw representation of
the network; ideally, I'd like to be abl
Hi Martin,
You may already know the benchmark done by Erwan's team with some java
implementations
(http://conference.osgeo.org/index.php/foss4g/2008/paper/view/282/177)
It eventually shows the triangulator I have written a few years ago
(available on http://geo.michaelm.free.fr/OpenJUMP/resourc
2009/4/29 Michaël Michaud
> Hi Martin,
>
> You may already know the benchmark done by Erwan's team with some java
> implementations (
> http://conference.osgeo.org/index.php/foss4g/2008/paper/view/282/177)
> It eventually shows the triangulator I have written a few years ago
> (available on http:
2009/4/29 Michaël Michaud
> Hi Martin,
>
> You may already know the benchmark done by Erwan's team with some java
> implementations (
> http://conference.osgeo.org/index.php/foss4g/2008/paper/view/282/177)
> It eventually shows the triangulator I have written a few years ago
> (available on http:
18 matches
Mail list logo
