>> > Not too bad. Could you fill a bug report so that we remember there is a > fix to do on this plugin.
Sure, done. > Did you already use the "Edit>Extract>Extract by geometry type" PlugIn ? > It is perfectly suited to handle shapefile with heterogeneous geometries. > I'd prefer this solution from deleting empty geometries without letting > the user know. > Maybe we can through a more explicit message to the user trying to > export a heterogeneous shapefile to make him know about this tool. > I didn't know about the "Extract by geometry type" plugin. Very handy! I tried it and it extracted the polygon (area) features, but not the geometrycollection features. I'm not familiar enough with this plugin to determine if this behavior would be surprising to a user, but it would let the user accomplish the task of filtering out the empty geometries. >From a user's standpoint, I think it would be helpful if the shapefile export referred the user to "Extract by geometry type" plugin when the user tries to export a mixed-geometry layer to a shapefile. -lreeder > Michaël >> -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 >> >> >> > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
