Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

Hi,i used empty geomcollection so far, to have something there... I am not sure how much work it would be to introduce a new table/data layer without a geometry - as i am not sure if OJ is designed for that. Simplest may be to copy and make the field invisible for now. Perhaps Michaël has a

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

i guess the cleanest solution would be a new layer class eg. DataLayer, that simply does not allow adding/editing geometries or does not even have a geometry attribute. in the 2nd case you would probably need a new featurecollection w/o a geometry column as well and the whole thing would throw

Re: [JPP-Devel] r5187

Thanks Michael. I will take time to translate all language codes before new real. Peppe Il 14/Nov/2016 09:02, "Michaël Michaud" ha scritto: > Hi Jumpers, > > In r5187, I deactivated disjoint predicate in spatial query, simple > query and simple join plugins. > > The

Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

Thanks Michael Ede Indeed I came across (as a side relative problem ) working on Saxtante. Sextante allows to work on Table files while Oj not. We can take advance of the Sextante table algorithms allowing Sextante to decode the vector layers, with all features with empty geometries (see for

[JPP-Devel] r5187

Hi Jumpers, In r5187, I deactivated disjoint predicate in spatial query, simple query and simple join plugins. The reason is that this operation is generally felt as buggy by users even if it is not really. As for other operators, using this predicate with layers containing several features