Hi,
It would be a correct behaviour to get nulls instead of zeros, I hope you can
fix it. But check what happens if some attribute in a table or in the result
set of a query contains only NULLs. The attribute field should still appear to
OpenJUMP layer schema, and it should be of a correct dat
Hi,
Is anybody preparing workshop or tutorial about OpenJUMP for FOSS4G
2010?
http://2010.foss4g.org/workshop.php
-Jukka Rahkonen-
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with
I don't use OpenJUMP with databases, but these are interesting issues.
Jukka wrote: "So what do developers think about what to do with
features which do not have geometry? I am remembering that JUMP
itself does not necessarily need geometry and I am rather sure that I
have even seen such things i
Stefan,
Thanks for the notice. I'm glad to hear you are busy at the
university. I will try to remember to forward you important JPP
e-mails.
SS
On Sun, Jan 24, 2010 at 2:54 PM, Stefan Steiniger wrote:
> Dear users and developers,
>
> I have been and are quite busy with some university things la
I think in the past I"ve used the convention that null geometry is
represented as GEOMETRYCOLLECTION EMPTY. That way most or all of the
JUMP functions should still work, but the user doesn't have to try and
distinguish between a real geometry and one which is just a placeholder
for null.
Idea
Hei Nikos,
I have no idea if there is way to eliminate the problem (as both printer
plugins are from external contributors), but thanks for telling us how
to work around this issue.
Is it actually the printer plugin from our sourceforge download site?
Because there is a second print plugin fro
Well, maybe we need to put together a list of places where OpenJUMP
might choke on a null geometry, and then we can test a fix.
Here is a start:
1) When the feature is about to be rendered.
2) When the user attempts to select the feature on the screen from the
attribute table.
3) When the user at
I don't think I can make it, as I plan to be at the same time at a field
course. However, no real decision yet - but I assume that if I know, the
deadline for workshops is gone.
stefan
Rahkonen Jukka wrote:
> Hi,
>
> Is anybody preparing workshop or tutorial about OpenJUMP for FOSS4G 2010?
>
I don't think selecting features with null geometry should be a
problem. As you say, this can only be done in the Attribute View, not
spatially - but the behaviour of the selected feature should be pretty
straightforward. It's in the selection set, but just isn't displayed.
Another issue w
Rahkonen Jukka a écrit :
> Hi,
>
> It would be a correct behaviour to get nulls instead of zeros, I hope you can
> fix it. But check what happens if some attribute in a table or in the result
> set of a query contains only NULLs. The attribute field should still appear
> to OpenJUMP layer schem
Hi,
> I don't recall that OpenJUMP can handle having a feature with no
> geometry. If nothing else, I think it would choke the renderer and
> would throw a null pointer exception. I could be wrong. Maybe one of
> the other programmers can comment.
>
I think the same thing
> I suppose it would be
Martin Davis a écrit :
> I think in the past I"ve used the convention that null geometry is
> represented as GEOMETRYCOLLECTION EMPTY. That way most or all of the
> JUMP functions should still work, but the user doesn't have to try and
> distinguish between a real geometry and one which is just
I'm not real happy with my "create a geometry around the origin" hack
for the DB Query Plugin, and it would be awesome if OJ had some way to
represent null geometries. I tweaked my DB Query plugin to return
empty geometry collections as suggested, and everything seemed to work
fine with a set of
Hi Larry,
Nice to hear you already tested GeometryCollection solution.
> to work, except Tools-->Statistics-->Layer Attribute Statistics, which
> threw the following NPE:
>
> java.lang.NullPointerException
> at
> org.openjump.core.apitools.FeatureCollectionTools.getMeanOrModeForAttributes(F
14 matches
Mail list logo
