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 6 features, all with empty geometries. I then
edited the layer and manually added a geometry, and most things seemed
to work, except Tools-->Statistics-->Layer Attribute Statistics, which
threw the following NPE:
java.lang.NullPointerException
at
org.openjump.core.apitools.FeatureCollectionTools.getMeanOrModeForAttributes(FeatureCollectionTools.java:254)
at
org.openjump.core.ui.plugin.tools.statistics.StatisticOverViewTableModel.setupTable(StatisticOverViewTableModel.java:75)
at
org.openjump.core.ui.plugin.tools.statistics.StatisticOverViewTableModel.<init>(StatisticOverViewTableModel.java:55)
at
org.openjump.core.ui.plugin.tools.statistics.StatisticOverViewDialog.<init>(StatisticOverViewDialog.java:61)
at
org.openjump.core.ui.plugin.tools.statistics.StatisticOverViewPlugIn.execute(StatisticOverViewPlugIn.java:102)
at
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:130)
at
com.vividsolutions.jump.workbench.ui.plugin.FeatureInstaller$4$1.run(FeatureInstaller.java:574)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:226)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:602)
I also had a problem saving the 6 empty geometry features + 1 polygon
feature as a shapefile because the geometry types were mixed, which
shapefile doesn't support. I guess in a regular instance where this
happens the user would manually find and delete one or the other type
of geometry, but I think there might be some usability problems
finding and deleting empty GeometryCollections from a layer. Perhaps
the shapefile export could do this automatically for the user?
-lreeder
2010/1/28 Michaël Michaud <michael.mich...@free.fr>:
> 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 a placeholder
>> for null.
>>
> Seems the best approach. I already saw this behaviour in OJ. Must check
> how postgis driver manage this case.
>> Ideally JUMP would be able to handle null geometries in the GEOMETRY
>> column as well - this should be fairly easy to add in, since it mostly
>> just means checking and returning before doing anything.
>>
> Do you mean returning a GEOMETRYCOLLECTION EMPTY instead of null in
> some base classes like BasicFeature.getGeometry() ?
> Should be interesting to try...
>
> Michaël
>> Rahkonen Jukka wrote:
>>
>>> 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 data
>>> type.
>>>
>>> More fundamental question is what to do if geometry field is NULL. It is
>>> not so uncommon situation with databases, and the aim of many GIS projects
>>> is just to add spatial data for existing objects with already known
>>> attribute data by locating them on map.
>>>
>>> At present if the result of a PostGIS query contains only NULL geometries
>>> OpenJUMP throws a Null Pointer Exception. If there are both real geometries
>>> and NULL geometries in the result se, the lines which are missing geometry
>>> are skipped.
>>>
>>> A DB Query Plugin by Larry Reeder is using a workaroud that has been very
>>> usable for me: if geometry is missing the plugin creates a default geometry
>>> as a little rectangle polygon at the origo. By that way user gets the
>>> schema and attributes to OpenJUMP even if the geometry is empty. What is
>>> missing is a clever tool for digitizing the real geometry and inserting it
>>> in place of the default geometry.
>>>
>>> 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 in
>>> OpenJUMP. I quess I got them to OpenJUMP through opening some shapefile.
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>>
>>> Michaël Michaud wrote:
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> I've got a question for database experts.
>>>> In DatabaseQueryPlugIn, the following JDBC methods are used to get
>>>> numeric attributes from database features
>>>> - ResultSet.getInt()
>>>> - ResultSet.getDouble()
>>>> those methods return an int and a double, even if the
>>>> database contains
>>>> NULL
>>>> NULL : getInt() --> 0
>>>> NULL : getDouble() --> 0.0
>>>> I think that OpenJUMP should get a null value each time the database
>>>> contains a NULL value.
>>>>
>>>> If this there is no special reason to use those methods, I'll
>>>> change the
>>>> code to get null instead of 0 in this special cases.
>>>>
>>>> Thanks for any suggestion
>>>>
>>>> Michaël
>>>>
>>>> NB : I noticed another problem with null handling in
>>>> SimpleQueryPlugIn.
>>>> I fixed it in the svn that way :
>>>> select features from layer1 where name = (empty combo box)
>>>> now returns
>>>> empty strings AND nulls (empty strings and null are very similar from
>>>> the end-user point of view)
>>>> I added "is null" as a function to be able to differentiate null from
>>>> empty string cases
>>>> There maybe some corner cases which are still not perfectly handled
>>>> (when there are null in the dataset and the operator is not
>>>> "equal" for
>>>> example)
>>>>
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
