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

[Michaël Michaud]

Hi,

Renaming attributes to be compatible with shapefile specification is a 
common need.
I also had this need and decided to go through configuration files. With 
layers having
20 to 30 attributes each, if you have to rename attributes more than one 
or two times,
a graphical interface will not do it.

Currently, I just have a quick and dirty plugin, and I'm not completely 
satisfied with it
but I would be happy do discuss possible improvements. Current choices 
and limitations :
1 - not linked with drivers : layer names and attribute names are 
changed in the project
  -> not possible to remove geometry column
2 - renaming is not undoable
 (structure change is generally not undoable in OpenJUMP)
3 - I choose plain text file rather than xml to keep it as simple as 
possible

Notice : this is more a ETL capability. Wonder if it could be integrated 
to Sextante
modeler.

Michaël


Le 15/11/2016 à 21:49, Rahkonen Jukka (MML) a écrit :
> Good idea. How about having an option to rename the columns to be exported by 
> the same?  Would be handy for example when exporting columns with long names 
> into shapefiles when automatic truncation can create non-informative names.
>
> -Jukka Rahkonen-
>
> edgar soldin wrote:
>
>> maybe a panel to select the columns to be exported for the selected format 
>> would be A. reusable B. fitting for several formats (eg. csv, json).
> ..ede
>
>> On 15.11.2016 18:44, Giuseppe Aruta wrote:
>>> Hi everybody
>>> and thanks for the comments
>>>
>>> @Ede >can CSV writer ignore geoms if i want to write a plain data table?
>>> This is a good point. As CSV exporter also saves geometries in WKT.
>>> I did a couple of tests (exporting large shapefiles of Italian
>>> Regions/Provinces to csv), my LibreOffice speadsheet easly opened them
>>> (after a couple of quirks that the test is too long). Than I can
>>> delete the geometry columns and work with the other info
>> --
>>
>> Anyhow, going back to my modification. The problem cames out from the
>> following boolean
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *public static boolean isTable(Layer layer) { FeatureCollectionWrapper
>> featureCollection = layer
>> .getFeatureCollectionWrapper();List featureList =
>> featureCollection.getFeatures();Geometry nextGeo = null;for
>> (@SuppressWarnings("unchecked")Iterator i
>> = featureList.iterator(); i.hasNext();) {
>> Feature feature = (Feature) i.next();nextGeo =
>> feature.getGeometry();}if (!featureCollection.isEmpty() &&
>> nextGeo.isEmpty()) {return true;} else {
>> return false;}}*
>> It is rought and self explaining (I am not a good developer). The
>> feature collection is scanned. If all the geometries associated to all
>> features are empty, it gives back true().
>>
>> I wonder if I can limit all the trouble on this method, finding a
>> simpler and less invasive solution. Just a couple of idea:
>> It scan only over  the first 1000 of features or it does a random scan
>> over only 1000 features.
>>
>> There will be probably other simpler solutions. Any  idea is welcome.
>>
>>
>> @Michael. Thanks for the nice explanation. Very intuitive for the pictures.
>> Unfortunately it requires a hard job, more that the my (or our) target.
>>
>> Best regards
>>
>> Peppe
>>
>>
>>
>>
>> 2016-11-15 12:41 GMT+01:00 :
>>
>>> Mike,
>>>
>>> i see your point. i'd vote to stick what we've got then and simply
>>> autocreate empty geometries as we do now. just curious, can CSV
>>> writer ignore geoms if i want to write a plain data table?
>>>
>>> ..ede
>>>
>>> On 15.11.2016 09:02, Michaël Michaud wrote:
 Hi,

 If I had to refactor the layer hierarchy to include datasets without
>>> geometry, I would probably try something like that
 (note that it would be a big refactoring, and I am not able to
 evaluate
>>> the workload to achieve it)
 Current layer hierarchy

 Current layer hierarchy

 Proposition to include non-geometric data (and to factorize some
>>> attributes)

 Proposed layer hierachy
 Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
> 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 better idea about the possibility to throw
> out
>>> the geom.
>
>
> cheers,
>
> stefan
>
>
>
> -- Originalnachricht --
> *Von: *
> *Datum: *14.11.2016 9:45
> *An: *OpenJump develop and use;
> *Betreff:*Re: [JPP-Devel] SVN: [5185] core/trunk/src/com/
>>> vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
> i guess the 

[JPP-Devel] SVN: [5190] core/trunk

[jump-pilot-svn]

Revision: 5190
  http://sourceforge.net/p/jump-pilot/code/5190
Author:   michaudm
Date: 2016-11-15 22:15:19 + (Tue, 15 Nov 2016)
Log Message:
---
Fix #353 Dialogs do not use preferred size on dual screen

Modified Paths:
--
core/trunk/ChangeLog
core/trunk/src/com/vividsolutions/jump/workbench/ui/GUIUtil.java

Modified: core/trunk/ChangeLog
===
--- core/trunk/ChangeLog2016-11-15 11:31:49 UTC (rev 5189)
+++ core/trunk/ChangeLog2016-11-15 22:15:19 UTC (rev 5190)
@@ -3,6 +3,9 @@
 # 2. make sure that lines break at 80 chars for constricted display situations
 #< 80 chars 
-->#
 
+2016-11-15 mmichaud 
+  * Fix #353 Dialogs do not use preferred size on dual screen
+
 2016-11-14 mmichaud 
   * deactivate the misleading disjoint predicate in query and join plugins
   * #FR 249 - add "intersects interior point" and "interior point intersects"

Modified: core/trunk/src/com/vividsolutions/jump/workbench/ui/GUIUtil.java
===
--- core/trunk/src/com/vividsolutions/jump/workbench/ui/GUIUtil.java
2016-11-15 11:31:49 UTC (rev 5189)
+++ core/trunk/src/com/vividsolutions/jump/workbench/ui/GUIUtil.java
2016-11-15 22:15:19 UTC (rev 5190)
@@ -388,7 +388,7 @@
   public static void centre(Component componentToMove,
   Component componentToCentreOn) {
 int offset = 30;
-Dimension screendim = Toolkit.getDefaultToolkit().getScreenSize();
+Dimension screendim = getMultiScreenDimension();
 Dimension componentToCentreOnSize = componentToCentreOn.getSize();
 int newx = componentToCentreOn.getX()
 + ((componentToCentreOnSize.width - componentToMove.getWidth()) / 2);
@@ -413,6 +413,18 @@
 componentToMove.setBounds(newx, newy, neww, newh);
   }
 
+  private static Dimension getMultiScreenDimension() {
+GraphicsDevice[] gds = 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
+int w = 0, h = 0;
+for (GraphicsDevice gd : gds) {
+  Rectangle r = gd.getDefaultConfiguration().getBounds();
+  if (r.getX()+r.getWidth() > w) w = (int)(r.getX()+r.getWidth());
+  if (r.getY()+r.getHeight() > h) h = (int)(r.getY()+r.getHeight());
+  System.out.println(r);
+}
+return new Dimension(w, h);
+  }
+
   /**
* Centres the component on the screen
* 


--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

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

[Rahkonen Jukka (MML)]

Good idea. How about having an option to rename the columns to be exported by 
the same?  Would be handy for example when exporting columns with long names 
into shapefiles when automatic truncation can create non-informative names.

-Jukka Rahkonen-

edgar soldin wrote:

> maybe a panel to select the columns to be exported for the selected format 
> would be A. reusable B. fitting for several formats (eg. csv, json).

..ede

> On 15.11.2016 18:44, Giuseppe Aruta wrote:
>> Hi everybody
>> and thanks for the comments
>> 
>> @Ede >can CSV writer ignore geoms if i want to write a plain data table?
>> This is a good point. As CSV exporter also saves geometries in WKT.
>> I did a couple of tests (exporting large shapefiles of Italian 
>> Regions/Provinces to csv), my LibreOffice speadsheet easly opened them 
>> (after a couple of quirks that the test is too long). Than I can 
>> delete the geometry columns and work with the other info
> 
> --
> 
> Anyhow, going back to my modification. The problem cames out from the 
> following boolean
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *public static boolean isTable(Layer layer) { FeatureCollectionWrapper 
> featureCollection = layer
> .getFeatureCollectionWrapper();List featureList =
> featureCollection.getFeatures();Geometry nextGeo = null;for
> (@SuppressWarnings("unchecked")Iterator i
> = featureList.iterator(); i.hasNext();) {
> Feature feature = (Feature) i.next();nextGeo =
> feature.getGeometry();}if (!featureCollection.isEmpty() &&
> nextGeo.isEmpty()) {return true;} else {
> return false;}}*
> It is rought and self explaining (I am not a good developer). The 
> feature collection is scanned. If all the geometries associated to all 
> features are empty, it gives back true().
> 
> I wonder if I can limit all the trouble on this method, finding a 
> simpler and less invasive solution. Just a couple of idea:
> It scan only over  the first 1000 of features or it does a random scan 
> over only 1000 features.
> 
> There will be probably other simpler solutions. Any  idea is welcome.
> 
> 
> @Michael. Thanks for the nice explanation. Very intuitive for the pictures.
> Unfortunately it requires a hard job, more that the my (or our) target.
> 
> Best regards
> 
> Peppe
> 
> 
> 
> 
> 2016-11-15 12:41 GMT+01:00 :
> 
>> Mike,
>>
>> i see your point. i'd vote to stick what we've got then and simply 
>> autocreate empty geometries as we do now. just curious, can CSV 
>> writer ignore geoms if i want to write a plain data table?
>>
>> ..ede
>>
>> On 15.11.2016 09:02, Michaël Michaud wrote:
>>> Hi,
>>>
>>> If I had to refactor the layer hierarchy to include datasets without
>> geometry, I would probably try something like that
>>> (note that it would be a big refactoring, and I am not able to 
>>> evaluate
>> the workload to achieve it)
>>>
>>> Current layer hierarchy
>>>
>>> Current layer hierarchy
>>>
>>> Proposition to include non-geometric data (and to factorize some
>> attributes)
>>>
>>>
>>> Proposed layer hierachy
>>> Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :

 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 better idea about the possibility to throw 
 out
>> the geom.



 cheers,

 stefan



 -- Originalnachricht --
 *Von: *
 *Datum: *14.11.2016 9:45
 *An: *OpenJump develop and use;
 *Betreff:*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 some 
>> exceptions here and there, as OJ expects geometries in 
>> featurecollections, but apart from that it would be clean and the 
>> renderer would not need to monitor geom changes at all.

 ..ede

 On 14.11.2016 10:39, Giuseppe Aruta wrote:
> 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 
> instance
>> loading
> .csv on auto mode) as tables (I already added added into Sextante
>> 

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

[edgar . soldin]

ok. A. equals B. there, i mean A. flexible B. reusable.. ede

On 15.11.2016 21:21, edgar.sol...@web.de wrote:
> maybe a panel to select the columns to be exported for the selected format 
> would be A. reusable B. fitting for several formats (eg. csv, json).
> 
> ..ede
> 
> On 15.11.2016 18:44, Giuseppe Aruta wrote:
>> Hi everybody
>> and thanks for the comments
>>
>> @Ede >can CSV writer ignore geoms if i want to write a plain data table?
>> This is a good point. As CSV exporter also saves geometries in WKT.
>> I did a couple of tests (exporting large shapefiles of Italian
>> Regions/Provinces to csv), my LibreOffice speadsheet easly opened them (after
>> a couple of quirks that the test is too long). Than I can delete the
>> geometry columns and work with the other info
>>
>> --
>>
>> Anyhow, going back to my modification. The problem cames out from the
>> following boolean
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *public static boolean isTable(Layer layer) {
>> FeatureCollectionWrapper featureCollection = layer
>> .getFeatureCollectionWrapper();List featureList =
>> featureCollection.getFeatures();Geometry nextGeo = null;for
>> (@SuppressWarnings("unchecked")Iterator i
>> = featureList.iterator(); i.hasNext();) {
>> Feature feature = (Feature) i.next();nextGeo =
>> feature.getGeometry();}if (!featureCollection.isEmpty() &&
>> nextGeo.isEmpty()) {return true;} else {
>> return false;}}*
>> It is rought and self explaining (I am not a good developer). The feature
>> collection is scanned. If all the geometries associated to all features are
>> empty, it gives back true().
>>
>> I wonder if I can limit all the trouble on this method, finding a simpler
>> and less invasive solution. Just a couple of idea:
>> It scan only over  the first 1000 of features
>> or
>> it does a random scan over only 1000 features.
>>
>> There will be probably other simpler solutions. Any  idea is welcome.
>>
>>
>> @Michael. Thanks for the nice explanation. Very intuitive for the pictures.
>> Unfortunately it requires a hard job, more that the my (or our) target.
>>
>> Best regards
>>
>> Peppe
>>
>>
>>
>>
>> 2016-11-15 12:41 GMT+01:00 :
>>
>>> Mike,
>>>
>>> i see your point. i'd vote to stick what we've got then and simply
>>> autocreate empty geometries as we do now. just curious, can CSV writer
>>> ignore geoms if i want to write a plain data table?
>>>
>>> ..ede
>>>
>>> On 15.11.2016 09:02, Michaël Michaud wrote:
 Hi,

 If I had to refactor the layer hierarchy to include datasets without
>>> geometry, I would probably try something like that
 (note that it would be a big refactoring, and I am not able to evaluate
>>> the workload to achieve it)

 Current layer hierarchy

 Current layer hierarchy

 Proposition to include non-geometric data (and to factorize some
>>> attributes)


 Proposed layer hierachy
 Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
>
> 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 better idea about the possibility to throw out
>>> the geom.
>
>
>
> cheers,
>
> stefan
>
>
>
> -- Originalnachricht --
> *Von: *
> *Datum: *14.11.2016 9:45
> *An: *OpenJump develop and use;
> *Betreff:*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 some exceptions
>>> here and there, as OJ expects geometries in featurecollections, but apart
>>> from that it would be clean and the renderer would not need to monitor geom
>>> changes at all.
>
> ..ede
>
> On 14.11.2016 10:39, Giuseppe Aruta wrote:
>> 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 instance
>>> loading
>> .csv on auto mode) as tables (I already added added into Sextante
>>> binding a
>> Boolean method that allows to decode these files).
>> I wondered if users would also have 

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

[Giuseppe Aruta]

Hi everybody
and thanks for the comments

@Ede >can CSV writer ignore geoms if i want to write a plain data table?
This is a good point. As CSV exporter also saves geometries in WKT.
I did a couple of tests (exporting large shapefiles of Italian
Regions/Provinces to csv), my LibreOffice speadsheet easly opened them (after
a couple of quirks that the test is too long). Than I can delete the
geometry columns and work with the other info

--

Anyhow, going back to my modification. The problem cames out from the
following boolean



















*public static boolean isTable(Layer layer) {
FeatureCollectionWrapper featureCollection = layer
.getFeatureCollectionWrapper();List featureList =
featureCollection.getFeatures();Geometry nextGeo = null;for
(@SuppressWarnings("unchecked")Iterator i
= featureList.iterator(); i.hasNext();) {
Feature feature = (Feature) i.next();nextGeo =
feature.getGeometry();}if (!featureCollection.isEmpty() &&
nextGeo.isEmpty()) {return true;} else {
return false;}}*
It is rought and self explaining (I am not a good developer). The feature
collection is scanned. If all the geometries associated to all features are
empty, it gives back true().

I wonder if I can limit all the trouble on this method, finding a simpler
and less invasive solution. Just a couple of idea:
It scan only over  the first 1000 of features
or
it does a random scan over only 1000 features.

There will be probably other simpler solutions. Any  idea is welcome.


@Michael. Thanks for the nice explanation. Very intuitive for the pictures.
Unfortunately it requires a hard job, more that the my (or our) target.

Best regards

Peppe




2016-11-15 12:41 GMT+01:00 :

> Mike,
>
> i see your point. i'd vote to stick what we've got then and simply
> autocreate empty geometries as we do now. just curious, can CSV writer
> ignore geoms if i want to write a plain data table?
>
> ..ede
>
> On 15.11.2016 09:02, Michaël Michaud wrote:
> > Hi,
> >
> > If I had to refactor the layer hierarchy to include datasets without
> geometry, I would probably try something like that
> > (note that it would be a big refactoring, and I am not able to evaluate
> the workload to achieve it)
> >
> > Current layer hierarchy
> >
> > Current layer hierarchy
> >
> > Proposition to include non-geometric data (and to factorize some
> attributes)
> >
> >
> > Proposed layer hierachy
> > Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :
> >>
> >> 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 better idea about the possibility to throw out
> the geom.
> >>
> >>
> >>
> >> cheers,
> >>
> >> stefan
> >>
> >>
> >>
> >> -- Originalnachricht --
> >> *Von: *
> >> *Datum: *14.11.2016 9:45
> >> *An: *OpenJump develop and use;
> >> *Betreff:*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 some exceptions
> here and there, as OJ expects geometries in featurecollections, but apart
> from that it would be clean and the renderer would not need to monitor geom
> changes at all.
> >>
> >> ..ede
> >>
> >> On 14.11.2016 10:39, Giuseppe Aruta wrote:
> >> > 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 instance
> loading
> >> > .csv on auto mode) as tables (I already added added into Sextante
> binding a
> >> > Boolean method that allows to decode these files).
> >> > I wondered if users would also have benefit  to visualize that a
> table is
> >> > loaded into OJ workbench, with a table icon.
> >> > I will check other solutions. Thanks for the hint.
> >> > Peppe
> >> >
> >> > Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
> >> > scritto:
> >> >
> >> >> Hi Peppe,
> >> >>
> >> >> Seel also my answer on 2016-10-29.
> >> >>
> >> >> TreeLayerNamePanel has a listener, but to avoid a featureCollection
> scan
> >> >> after each change
> >> >> you probably need to keep a cache in the Layer as suggested by Ede,
> and
> >> >> use the Layer's
> >> >> listener to update the cache every time a 

Re: [JPP-Devel] GeoJSON rfc7946

[Rahkonen Jukka (MML)]

Hello Brian,

I appreciate the standards and I know quite well GDAL GeoJSON driver which by 
the way is still having the GeoJSON 2008 as default. User must especially ask 
for RFC7946 with a layer creation option.

Why I still prefer the 2008 version is that I am mostly working with data that 
are not natively in EPSG:4326 and I am using WFS services a lot. From a WFS 
users point of view it makes a lot of sense to get exactly the same coordinates 
if only the outputformat is changing from GML into GeoJSON.

http://hip.latuviitta.org/cgi-bin/tinyows?service=wfs=1.0.0=getfeature=lv:pks_juna_asemat=1

http://hip.latuviitta.org/cgi-bin/tinyows?service=wfs=1.0.0=getfeature=lv:pks_juna_asemat=1=application/json

I think that dropping the support for crs in GeoJSON was fixing something that 
was not really broken. I have changed friendly emails with misters Gillies and 
Daly and I know that they do not agree.  I also know that rfc7946 allows use of 
other coordinate systems:

"However, where all involved parties have a prior arrangement, alternative 
coordinate
reference systems can be used without risk of data being misinterpreted."

A self explaining, internal CRS element inside the GeoJSON file would have been 
the "a prior arrangement" for my mind. Otherwise the situation with 
non-EPSG:4326 GeoJSON will be the same that what we have with shapefiles which 
are missing the .prj part.

When it comes to the GeoJSON driver of OpenJUMP, I do not believe that 
supporting only GeoJSON 2008 for writing is an critical issue. I do not believe 
that GeoJSON that is created with OpenJUMP is so often used directly by browser 
apps, heavier clients like GDAL can read 2008 version without problems, and 
OpenJUMP can read both versions.

JTS and GEOS have been used for big data also before, and license change of JTS 
does not affect the GEOS port.

-Jukka Rahkonen-


Lähettäjä: Brian M Hamlin 
Lähetetty: 15. marraskuuta 2016 17:50
Vastaanottaja: Rahkonen Jukka (MML); jump-pilot-devel@lists.sourceforge.net
Aihe: GeoJSON rfc7946

Hi OpenJUMP devs -  from a user point of view, standards are valuable !!   
There is a massive increase in the use of GeoJSON in web development, and also 
(but less) in desktop GIS.  OpenJUMP and users will benefit from emitting 
standard 4326 geoJSON.   If you want to emit CRS geoJSON, you can, however 
please consider that as a clear user option only. Here is the current GDAL 
geoJSON driver for guidance.http://www.gdal.org/drv_geojson.html   ps - 
I am using OpenJUMP 1.9 rev 4795  today and many days, to generate PostGIS 
summary geometry for a large project here in California. Also you may know that 
JTS license was changed last January, and new bigdata applications 
are now building geometry processing using JTS primitives.   thank you very 
much and best wishes  --Brian M Hamlin

On Tue, 15 Nov 2016 11:38:02 +, Rahkonen Jukka (MML)  wrote:


edgar soldin wrote:

  The geojsonhint project is at 
https://github.com/mapbox/geojsonhint. Releases before 2.0 (such as 1.2.1, from 
May 20016) will validate legacy GeoJSON.

 what does that mean for us? sorry, there is no sun here today, so my 
batteries are very low.

It means that if we instead of http://geojson.org/geojson-spec.html try to 
follow https://tools.ietf.org/html/rfc7946 we should re-project data into 
EPSG:4326 longitude-latitude and drop the crs member.  However, people do 
continue to use other projections. If you feel yourself very kind you could 
make that selectable Write GeoJSON 2008 with crs/Write 
rfc7946 GeoJSON.  The latter requires that CRS plugin is installed. For 
my mind the newer specification is not better.

-Jukka-


..ede

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] GeoJSON rfc7946

[Brian M Hamlin]

Hi OpenJUMP devs -  from a user point of view, standards are valuable !!   
There is a massive increase in the use of GeoJSON in web development, and also 
(but less) in desktop GIS.  OpenJUMP and users will benefit from emitting 
standard 4326 geoJSON.   If you want to emit CRS geoJSON, you can, however 
please consider that as a clear user option only. Here is the current GDAL 
geoJSON driver for guidance.http://www.gdal.org/drv_geojson.html   ps - 
I am using OpenJUMP 1.9 rev 4795  today and many days, to generate PostGIS 
summary geometry for a large project here in California. Also you may know that 
JTS license was changed last January, and new bigdata applications 
are now building geometry processing using JTS primitives.   thank you very 
much and best wishes  --Brian M Hamlin 

On Tue, 15 Nov 2016 11:38:02 +, Rahkonen Jukka (MML)  wrote:


edgar soldin wrote:
 
  The geojsonhint project is at 
https://github.com/mapbox/geojsonhint. Releases before 2.0 (such as 1.2.1, from 
May 20016) will validate legacy GeoJSON.
 
 what does that mean for us? sorry, there is no sun here today, so my 
batteries are very low.

It means that if we instead of http://geojson.org/geojson-spec.html try to 
follow https://tools.ietf.org/html/rfc7946 we should re-project data into 
EPSG:4326 longitude-latitude and drop the crs member.  However, people do 
continue to use other projections. If you feel yourself very kind you could 
make that selectable Write GeoJSON 2008 with crs/Write 
rfc7946 GeoJSON.  The latter requires that CRS plugin is installed. For 
my mind the newer specification is not better.

-Jukka-


..ede

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel


--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Invalid GeoJSON if no attributes

[edgar . soldin]

would you mind packing it and maybe some summer heat on the side as well and 
send it to cologne?

;).. ede de la Capital de los tontos

On 15.11.2016 14:29, Stefan Steiniger wrote:
> ede, got some sun for you on my metro ride to work.
> 
> stefan
> 
> -- Originalnachricht --
> *Von: *
> *Datum: *15.11.2016 8:27
> *An: *OpenJump develop and use;
> *Betreff:*Re: [JPP-Devel] Invalid GeoJSON if no attributes
> 
> On 15.11.2016 12:02, Rahkonen Jukka (MML) wrote:
>> Hi,
>>
>> One closing "}" seems to be missing. There is EPSG:0"}}} but should be one 
>> more.  Otherwise validates in jsonling.com and in geojsonlint.com.
> 
> whooops a typo ;)
> 
>> {
>> "type": "FeatureCollection",
>>
>> "features": [
>> { "type": "Feature", "properties" : null, "geometry": 
>> {"type":"Polygon","coordinates":[[[207,483],[343,524],[298,386],[207,483]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}}
>> ]
>>
>> }
>>
>>
>> I was testing another part of GeoJSON (winding order of polygons) while I 
>> noticed that the code that is run at geojsonlint.com has been changed so 
>> that it is nagging about crs. I asked and Sean Gillies answered:
>>
>> " The geojsonhint project is at https://github.com/mapbox/geojsonhint. 
>> Releases before 2.0 (such as 1.2.1, from May 20016) will validate legacy 
>> GeoJSON."
>>
> 
> what does that mean for us? sorry, there is no sun here today, so my 
> batteries are very low.
> 
> ..ede
> 
> --
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Invalid GeoJSON if no attributes

[Rahkonen Jukka (MML)]

edgar soldin wrote:
 
>> " The geojsonhint project is at https://github.com/mapbox/geojsonhint. 
>> Releases before 2.0 (such as 1.2.1, from May 20016) will validate legacy 
>> GeoJSON."
>> 
> what does that mean for us? sorry, there is no sun here today, so my 
> batteries are very low.

It means that if we instead of http://geojson.org/geojson-spec.html try to 
follow https://tools.ietf.org/html/rfc7946 we should re-project data into 
EPSG:4326 longitude-latitude and drop the crs member.  However, people do 
continue to use other projections. If you feel yourself very kind you could 
make that selectable "Write GeoJSON 2008 with crs"/"Write rfc7946 GeoJSON".  
The latter requires that CRS plugin is installed. For my mind the newer 
specification is not better.

-Jukka-


..ede

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Invalid GeoJSON if no attributes

[edgar . soldin]

should be fixed in r5189 ..ede

On 15.11.2016 12:27, edgar.sol...@web.de wrote:
> On 15.11.2016 12:02, Rahkonen Jukka (MML) wrote:
>> Hi,
>>
>> One closing "}" seems to be missing. There is EPSG:0"}}} but should be one 
>> more.  Otherwise validates in jsonling.com and in geojsonlint.com.
> 
> whooops a typo ;)
> 
>> {
>> "type": "FeatureCollection",
>>
>> "features": [
>> { "type": "Feature", "properties" : null, "geometry": 
>> {"type":"Polygon","coordinates":[[[207,483],[343,524],[298,386],[207,483]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}}
>> ]
>>
>> }
>>
>>
>> I was testing another part of GeoJSON (winding order of polygons) while I 
>> noticed that the code that is run at geojsonlint.com has been changed so 
>> that it is nagging about crs. I asked and Sean Gillies answered:
>>
>> " The geojsonhint project is at https://github.com/mapbox/geojsonhint. 
>> Releases before 2.0 (such as 1.2.1, from May 20016) will validate legacy 
>> GeoJSON."
>>
> 
> what does that mean for us? sorry, there is no sun here today, so my 
> batteries are very low.
> 
> ..ede
> 
> --
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] SVN: [5189] core/trunk/src/com/vividsolutions/jump/io/geojson

[jump-pilot-svn]

Revision: 5189
  http://sourceforge.net/p/jump-pilot/code/5189
Author:   edso
Date: 2016-11-15 11:31:49 + (Tue, 15 Nov 2016)
Log Message:
---
refine handling when geom or props are NULL

Modified Paths:
--
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java

core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java

Modified: 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java
===
--- core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java 
2016-11-15 10:02:05 UTC (rev 5188)
+++ core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java 
2016-11-15 11:31:49 UTC (rev 5189)
@@ -10,9 +10,4 @@
 
   public static final String TYPE_FEATURE = "Feature";
   public static final String TYPE_FEATURECOLLECTION = "FeatureCollection";
-
-  // for performance reasons, prevent concatenating the same string
-  public static final String EMPTY_GEOMETRY = "\"" + GEOMETRY
-  + "\": {\"type\":\"GeometryCollection\",\"geometries\":[]}";
-  public static final String EMPTY_PROPERTIES = "\"" + PROPERTIES + "\" : 
null";
 }

Modified: 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java
===
--- 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java
  2016-11-15 10:02:05 UTC (rev 5188)
+++ 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java
  2016-11-15 11:31:49 UTC (rev 5189)
@@ -166,8 +166,9 @@
   if (featureSchema.getAttributeType(key) == ATTRIBUTETYPE_NULL) {
 featureSchema.setAttributeType(key, type);
   }
-  // this column hosts mixed attrib types eg. String/Long, NULL values 
are allowed though
-  else if (type != ATTRIBUTETYPE_NULL){
+  // this column hosts mixed attrib types eg. String/Long, NULL values
+  // are allowed though
+  else if (type != ATTRIBUTETYPE_NULL) {
 columnsWithMixedValues.add(key);
   }
 }
@@ -215,7 +216,7 @@
*/
   public FeatureCollection getFeatureCollection() {
 // set type to String for mixed columns
-for (String key : new LinkedList(columnsWithMixedValues) ) {
+for (String key : new LinkedList(columnsWithMixedValues)) {
   featureSchema.setAttributeType(featureSchema.getAttributeIndex(key),
   AttributeType.STRING);
   columnsWithMixedValues.remove(key);
@@ -296,7 +297,7 @@
 Geometry geometry = (Geometry) value;
 if (geometry != null)
   geometryJson = new GeoJsonWriter().write(geometry);
-  } 
+  }
   // attrib to json
   else {
 // we do NOT save null values to minimize the file size
@@ -313,22 +314,18 @@
   }
 }
 
-// the GeoJSON specs expect a geometry to be written, it might be empty 
though
-if (geometryJson != null)
-  geometryJson = "\"" + GeoJSONConstants.GEOMETRY + "\": " + geometryJson;
-else
-  geometryJson = GeoJSONConstants.EMPTY_GEOMETRY;
+// the GeoJSON specs expect a geometry to be written, it might be null
+geometryJson = "\"" + GeoJSONConstants.GEOMETRY + "\": " + geometryJson;
 
-// the GeoJSON specs expect properties to be written, it might be null 
when empty
+// wrap array list, null value stays plain
 if (propertiesJson != null)
-  propertiesJson = "\"" + GeoJSONConstants.PROPERTIES + "\": { "
-  + propertiesJson + " }";
-else
-  propertiesJson = GeoJSONConstants.EMPTY_PROPERTIES;
+  propertiesJson = "{ " + propertiesJson + " }";
+// the GeoJSON specs expect properties to be written, it might be null
+propertiesJson = "\"" + GeoJSONConstants.PROPERTIES + "\": "
++ propertiesJson;
 
 return "{ \"" + GeoJSONConstants.TYPE + "\": \""
-+ GeoJSONConstants.TYPE_FEATURE + "\""
-+ ", " + propertiesJson
-+ ", " + geometryJson;
++ GeoJSONConstants.TYPE_FEATURE + "\"" + ", " + propertiesJson + ", "
++ geometryJson + " }";
   }
 }


--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Invalid GeoJSON if no attributes

[edgar . soldin]

On 15.11.2016 12:02, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> One closing "}" seems to be missing. There is EPSG:0"}}} but should be one 
> more.  Otherwise validates in jsonling.com and in geojsonlint.com.

whooops a typo ;)

> {
> "type": "FeatureCollection",
> 
> "features": [
> { "type": "Feature", "properties" : null, "geometry": 
> {"type":"Polygon","coordinates":[[[207,483],[343,524],[298,386],[207,483]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}}
> ]
> 
> }
> 
> 
> I was testing another part of GeoJSON (winding order of polygons) while I 
> noticed that the code that is run at geojsonlint.com has been changed so that 
> it is nagging about crs. I asked and Sean Gillies answered:
> 
> " The geojsonhint project is at https://github.com/mapbox/geojsonhint. 
> Releases before 2.0 (such as 1.2.1, from May 20016) will validate legacy 
> GeoJSON."
> 

what does that mean for us? sorry, there is no sun here today, so my batteries 
are very low.

..ede

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Invalid GeoJSON if no attributes

[Rahkonen Jukka (MML)]

Hi,

One closing "}" seems to be missing. There is EPSG:0"}}} but should be one 
more.  Otherwise validates in jsonling.com and in geojsonlint.com.

{
"type": "FeatureCollection",

"features": [
{ "type": "Feature", "properties" : null, "geometry": 
{"type":"Polygon","coordinates":[[[207,483],[343,524],[298,386],[207,483]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}}
]

}


I was testing another part of GeoJSON (winding order of polygons) while I 
noticed that the code that is run at geojsonlint.com has been changed so that 
it is nagging about crs. I asked and Sean Gillies answered:

" The geojsonhint project is at https://github.com/mapbox/geojsonhint. Releases 
before 2.0 (such as 1.2.1, from May 20016) will validate legacy GeoJSON."

-Jukka-


-Alkuperäinen viesti-
Lähettäjä: edgar.sol...@web.de [mailto:edgar.sol...@web.de] 
Lähetetty: 15. marraskuuta 2016 12:03
Vastaanottaja: OpenJump develop and use 
Aihe: Re: [JPP-Devel] Invalid GeoJSON if no attributes

Jukka,

please try r5188.. ede

On 15.11.2016 10:31, edgar.sol...@web.de wrote:
> from http://geojson.org/geojson-spec.html
> "
> A GeoJSON object with the type "Feature" is a feature object.
> 
> A feature object must have a member with the name "geometry". The value of 
> the geometry member is a geometry object as defined above or a JSON null 
> value.
> 
> A feature object must have a member with the name "properties". The value of 
> the properties member is an object (any JSON object or a JSON null value).
> "
> 
> so that means 
>"properties": null
> which validates on http://geojsonlint.com/
> 
> will fix it, did you came across a parser that did not like OJ generated 
> GeoJSON because of that?
> 
> ..ede
> On 15.11.2016 09:57, Rahkonen Jukka (MML) wrote:
>> Hi,
>>
>> In GeoJSON FeatureCollection must have "properties" member even if 
>> there are no attributes. This output from OpenJUMP r5186 does not 
>> validate
>>
>> {
>> "type": "FeatureCollection",
>>
>> "features": [
>> { "type": "Feature", "geometry": 
>> {"type":"Polygon","coordinates":[[[278,423],[483,505],[478,293],[278,
>> 423]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}} } ]
>>
>> }
>>
>> I am not sure if this is the right fix but at least it validates:
>> { "type": "Feature", "properties": { }, "geometry": 
>>
>> It seems that GeoJSONLint http://geojsonlint.com/ does not like the crs 
>> member any more because it belongs to older, year 2008 version of GeoJSON.  
>> However, I think that OpenJUMP should still output the old version that 
>> supports projections. I try to find some more flexible validator.
>>
>> -Jukka Rahkonen-
>> -
>> - ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> 
> --
>  ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

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

[edgar . soldin]

Jukka,

nothing to worry, my mind was w/ GeoJSON still and the only possibility to add 
an empty geom there is to use GeometryCollection because of the constraints i 
described.

my bad ..ede

On 15.11.2016 11:16, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> What do you mean? You did lot of work with empty geometries two years ago. In 
> December 1st, 2014 I answered you, probably after the final tests
> 
> "Hi Ede,
> 
> All this seems to work perfectly now:
> - Different empty geometries are visualized with corresponding icons
> - All kind of empty geometries can be saved into JUMP jml and FME GML and 
> returned as they were.
> - Empty geometries in shapefiles are handled in a reasonable way:
>  - "Extract layers by geometry type" extracts empty points to a point 
> layer, empty linestrings to a linestring layer etc.
> - Empty geometries which are read from a shapefile are marked to be empty 
> geometries of the same type as the not-empty geometries. A point shapefile 
> brings empty points, a line shapefile empty multilinestrings and a polygon 
> shape empty multipolygons. Because shapefiles do not make much difference 
> between simple and multivariants this is just right."
> 
> -Jukka-
> 
> -Alkuperäinen viesti-
> Lähettäjä: edgar.sol...@web.de [mailto:edgar.sol...@web.de] 
> Lähetetty: 15. marraskuuta 2016 12:11
> Vastaanottaja: Rahkonen Jukka (MML) ; 
> OpenJump develop and use 
> Aihe: Re: [JPP-Devel] SVN: [5185] 
> core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java
> 
> GeometryCollection is afaik the only possibility to have an empty geometry as 
> all other geom types require either coordinates or sub geoms per definition.
> 
> ..ede
> 
> On 15.11.2016 11:06, Rahkonen Jukka (MML) wrote:
>> Hi,
>>
>> DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the 
>> lines without a real geometry. For my purposes it has been a good solution 
>> but I can’t say if it suits for other use cases.
>>
>> -Jukka Rahkonen-
>>
>> Stefan Steiniger wrote:
>>
>>
>> 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 better idea about the possibility to throw out the 
>> geom.
>>
>>
>>
>> cheers,
>>
>> stefan
>>
>>
>> -- Originalnachricht --
>> Von:
>> Datum: 14.11.2016 9:45
>> An: OpenJump develop and use;
>> Betreff: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 some exceptions here 
>> and there, as OJ expects geometries in featurecollections, but apart from 
>> that it would be clean and the renderer would not need to monitor geom 
>> changes at all.
>>
>>
>>
>> ..ede
>>
>>
>>
>> On 14.11.2016 10:39, Giuseppe Aruta wrote:
>>
>>> 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 instance loading
>>
>>> .csv on auto mode) as tables (I already added added into Sextante binding a
>>
>>> Boolean method that allows to decode these files).
>>
>>> I wondered if users would also have benefit  to visualize that a table is
>>
>>> loaded into OJ workbench, with a table icon.
>>
>>> I will check other solutions. Thanks for the hint.
>>
>>> Peppe
>>
>>>
>>
>>> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
>>
>>> scritto:
>>
>>>
>>
 Hi Peppe,
>>

>>
 Seel also my answer on 2016-10-29.
>>

>>
 TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
>>
 after each change
>>
 you probably need to keep a cache in the Layer as suggested by Ede, and
>>
 use the Layer's
>>
 listener to update the cache every time a feature is added, removed or
>>
 changed
>>

>>
 Michaël
>>

>>

>>
 Le 13/11/2016 à 19:51, edgar.sol...@web.de a 
 écrit :
>>
> thanks.. how about implementing the caching/listener approach if you
>>
 like to have icon? ..ede
>>
>
>>
> On 13.11.2016 18:57, Giuseppe Aruta wrote:
>>
>> Ok Ede, I didn't  know it. I will revert the change.
>>
>> Thanks again
>>
>> Peppe
>>
>>
>>
>> Il 13/Nov/2016 18:48,  ha scritto:
>>
>>
>>
>>> Peppe,
>>

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

[Rahkonen Jukka (MML)]

Hi,

What do you mean? You did lot of work with empty geometries two years ago. In 
December 1st, 2014 I answered you, probably after the final tests

"Hi Ede,

All this seems to work perfectly now:
- Different empty geometries are visualized with corresponding icons
- All kind of empty geometries can be saved into JUMP jml and FME GML and 
returned as they were.
- Empty geometries in shapefiles are handled in a reasonable way:
 - "Extract layers by geometry type" extracts empty points to a point 
layer, empty linestrings to a linestring layer etc.
- Empty geometries which are read from a shapefile are marked to be empty 
geometries of the same type as the not-empty geometries. A point shapefile 
brings empty points, a line shapefile empty multilinestrings and a polygon 
shape empty multipolygons. Because shapefiles do not make much difference 
between simple and multivariants this is just right."

-Jukka-

-Alkuperäinen viesti-
Lähettäjä: edgar.sol...@web.de [mailto:edgar.sol...@web.de] 
Lähetetty: 15. marraskuuta 2016 12:11
Vastaanottaja: Rahkonen Jukka (MML) ; 
OpenJump develop and use 
Aihe: Re: [JPP-Devel] SVN: [5185] 
core/trunk/src/com/vividsolutions/jump/workbench/ui/ LayerNameRenderer.java

GeometryCollection is afaik the only possibility to have an empty geometry as 
all other geom types require either coordinates or sub geoms per definition.

..ede

On 15.11.2016 11:06, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the lines 
> without a real geometry. For my purposes it has been a good solution but I 
> can’t say if it suits for other use cases.
> 
> -Jukka Rahkonen-
> 
> Stefan Steiniger wrote:
> 
> 
> 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 better idea about the possibility to throw out the geom.
> 
> 
> 
> cheers,
> 
> stefan
> 
> 
> -- Originalnachricht --
> Von:
> Datum: 14.11.2016 9:45
> An: OpenJump develop and use;
> Betreff: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 some exceptions here 
> and there, as OJ expects geometries in featurecollections, but apart from 
> that it would be clean and the renderer would not need to monitor geom 
> changes at all.
> 
> 
> 
> ..ede
> 
> 
> 
> On 14.11.2016 10:39, Giuseppe Aruta wrote:
> 
>> 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 instance loading
> 
>> .csv on auto mode) as tables (I already added added into Sextante binding a
> 
>> Boolean method that allows to decode these files).
> 
>> I wondered if users would also have benefit  to visualize that a table is
> 
>> loaded into OJ workbench, with a table icon.
> 
>> I will check other solutions. Thanks for the hint.
> 
>> Peppe
> 
>>
> 
>> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
> 
>> scritto:
> 
>>
> 
>>> Hi Peppe,
> 
>>>
> 
>>> Seel also my answer on 2016-10-29.
> 
>>>
> 
>>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
> 
>>> after each change
> 
>>> you probably need to keep a cache in the Layer as suggested by Ede, and
> 
>>> use the Layer's
> 
>>> listener to update the cache every time a feature is added, removed or
> 
>>> changed
> 
>>>
> 
>>> Michaël
> 
>>>
> 
>>>
> 
>>> Le 13/11/2016 à 19:51, edgar.sol...@web.de a 
>>> écrit :
> 
 thanks.. how about implementing the caching/listener approach if you
> 
>>> like to have icon? ..ede
> 

> 
 On 13.11.2016 18:57, Giuseppe Aruta wrote:
> 
> Ok Ede, I didn't  know it. I will revert the change.
> 
> Thanks again
> 
> Peppe
> 
>
> 
> Il 13/Nov/2016 18:48,  ha scritto:
> 
>
> 
>> Peppe,
> 
>>
> 
>> NACK.. this is going to get very slow for huge datasets containing
> 
>>> empty
> 
>> geoms only, as it is run on every redraw of the layer tree. please
> 
>>> cache
> 
>> the state and use a layer change listener or else users will complain
> 
>>> about
> 
>> a frozen OJ some time in the future and we will have a hard time to
> 
>> pinpoint the reason, 

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

[edgar . soldin]

GeometryCollection is afaik the only possibility to have an empty geometry as 
all other geom types require either coordinates or sub geoms per definition.

..ede

On 15.11.2016 11:06, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the lines 
> without a real geometry. For my purposes it has been a good solution but I 
> can’t say if it suits for other use cases.
> 
> -Jukka Rahkonen-
> 
> Stefan Steiniger wrote:
> 
> 
> 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 better idea about the possibility to throw out the geom.
> 
> 
> 
> cheers,
> 
> stefan
> 
> 
> -- Originalnachricht --
> Von:
> Datum: 14.11.2016 9:45
> An: OpenJump develop and use;
> Betreff: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 some exceptions here 
> and there, as OJ expects geometries in featurecollections, but apart from 
> that it would be clean and the renderer would not need to monitor geom 
> changes at all.
> 
> 
> 
> ..ede
> 
> 
> 
> On 14.11.2016 10:39, Giuseppe Aruta wrote:
> 
>> 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 instance loading
> 
>> .csv on auto mode) as tables (I already added added into Sextante binding a
> 
>> Boolean method that allows to decode these files).
> 
>> I wondered if users would also have benefit  to visualize that a table is
> 
>> loaded into OJ workbench, with a table icon.
> 
>> I will check other solutions. Thanks for the hint.
> 
>> Peppe
> 
>>
> 
>> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha
> 
>> scritto:
> 
>>
> 
>>> Hi Peppe,
> 
>>>
> 
>>> Seel also my answer on 2016-10-29.
> 
>>>
> 
>>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan
> 
>>> after each change
> 
>>> you probably need to keep a cache in the Layer as suggested by Ede, and
> 
>>> use the Layer's
> 
>>> listener to update the cache every time a feature is added, removed or
> 
>>> changed
> 
>>>
> 
>>> Michaël
> 
>>>
> 
>>>
> 
>>> Le 13/11/2016 à 19:51, edgar.sol...@web.de a 
>>> écrit :
> 
 thanks.. how about implementing the caching/listener approach if you
> 
>>> like to have icon? ..ede
> 

> 
 On 13.11.2016 18:57, Giuseppe Aruta wrote:
> 
> Ok Ede, I didn't  know it. I will revert the change.
> 
> Thanks again
> 
> Peppe
> 
>
> 
> Il 13/Nov/2016 18:48,  ha scritto:
> 
>
> 
>> Peppe,
> 
>>
> 
>> NACK.. this is going to get very slow for huge datasets containing
> 
>>> empty
> 
>> geoms only, as it is run on every redraw of the layer tree. please
> 
>>> cache
> 
>> the state and use a layer change listener or else users will complain
> 
>>> about
> 
>> a frozen OJ some time in the future and we will have a hard time to
> 
>> pinpoint the reason, again ;)
> 
>>
> 
>> ..ede
> 
>>
> 
>> On 13.11.2016 18:41, 
>> jump-pilot-...@lists.sourceforge.net
>>  wrote:
> 
>>> Revision: 5185
> 
>>>http://sourceforge.net/p/jump-pilot/code/5185
> 
>>> Author:   ma15569
> 
>>> Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)
> 
>>> Log Message:
> 
>>> ---
> 
>>> The layer tree shows a table icon for layers that have features with
> 
>> empty geometries
> 
>>> Modified Paths:
> 
>>> --
> 
>>>  core/trunk/src/com/vividsolutions/jump/workbench/
> 
>> ui/LayerNameRenderer.java
> 
>>> Modified: core/trunk/src/com/vividsolutions/jump/workbench/
> 
>> ui/LayerNameRenderer.java
> 
>>> ===
> 
>>> --- core/trunk/src/com/vividsolutions/jump/workbench/
> 
>>> ui/LayerNameRenderer.java
> 
>>2016-11-13 17:21:20 UTC (rev 5184)
> 
>>> +++ core/trunk/src/com/vividsolutions/jump/workbench/
> 
>>> ui/LayerNameRenderer.java
> 
>>2016-11-13 17:41:37 UTC (rev 5185)
> 
>>> @@ -36,6 +36,7 @@
> 
>>>   import java.awt.Rectangle;
> 
>>>   import java.io.File;
> 
>>>   import java.util.Iterator;
> 

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

[Rahkonen Jukka (MML)]

Hi,

DB Query plugin is attaching a fake GEOMETRYCOLLECTION EMPTY to all the lines 
without a real geometry. For my purposes it has been a good solution but I 
can’t say if it suits for other use cases.

-Jukka Rahkonen-

Stefan Steiniger wrote:


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 better idea about the possibility to throw out the geom.



cheers,

stefan


-- Originalnachricht --
Von:
Datum: 14.11.2016 9:45
An: OpenJump develop and use;
Betreff: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 some exceptions here and there, 
as OJ expects geometries in featurecollections, but apart from that it would be 
clean and the renderer would not need to monitor geom changes at all.



..ede



On 14.11.2016 10:39, Giuseppe Aruta wrote:

> 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 instance loading

> .csv on auto mode) as tables (I already added added into Sextante binding a

> Boolean method that allows to decode these files).

> I wondered if users would also have benefit  to visualize that a table is

> loaded into OJ workbench, with a table icon.

> I will check other solutions. Thanks for the hint.

> Peppe

>

> Il 13/Nov/2016 23:21, "Michaël Michaud"  ha

> scritto:

>

>> Hi Peppe,

>>

>> Seel also my answer on 2016-10-29.

>>

>> TreeLayerNamePanel has a listener, but to avoid a featureCollection scan

>> after each change

>> you probably need to keep a cache in the Layer as suggested by Ede, and

>> use the Layer's

>> listener to update the cache every time a feature is added, removed or

>> changed

>>

>> Michaël

>>

>>

>> Le 13/11/2016 à 19:51, edgar.sol...@web.de a 
>> écrit :

>>> thanks.. how about implementing the caching/listener approach if you

>> like to have icon? ..ede

>>>

>>> On 13.11.2016 18:57, Giuseppe Aruta wrote:

 Ok Ede, I didn't  know it. I will revert the change.

 Thanks again

 Peppe



 Il 13/Nov/2016 18:48,  ha scritto:



> Peppe,

>

> NACK.. this is going to get very slow for huge datasets containing

>> empty

> geoms only, as it is run on every redraw of the layer tree. please

>> cache

> the state and use a layer change listener or else users will complain

>> about

> a frozen OJ some time in the future and we will have a hard time to

> pinpoint the reason, again ;)

>

> ..ede

>

> On 13.11.2016 18:41, 
> jump-pilot-...@lists.sourceforge.net
>  wrote:

>> Revision: 5185

>>http://sourceforge.net/p/jump-pilot/code/5185

>> Author:   ma15569

>> Date: 2016-11-13 17:41:37 + (Sun, 13 Nov 2016)

>> Log Message:

>> ---

>> The layer tree shows a table icon for layers that have features with

> empty geometries

>> Modified Paths:

>> --

>>  core/trunk/src/com/vividsolutions/jump/workbench/

> ui/LayerNameRenderer.java

>> Modified: core/trunk/src/com/vividsolutions/jump/workbench/

> ui/LayerNameRenderer.java

>> ===

>> --- core/trunk/src/com/vividsolutions/jump/workbench/

>> ui/LayerNameRenderer.java

>2016-11-13 17:21:20 UTC (rev 5184)

>> +++ core/trunk/src/com/vividsolutions/jump/workbench/

>> ui/LayerNameRenderer.java

>2016-11-13 17:41:37 UTC (rev 5185)

>> @@ -36,6 +36,7 @@

>>   import java.awt.Rectangle;

>>   import java.io.File;

>>   import java.util.Iterator;

>> +import java.util.List;

>>

>>   import javax.swing.DefaultListCellRenderer;

>>   import javax.swing.Icon;

>> @@ -54,9 +55,11 @@

>>   import org.openjump.core.rasterimage.RasterImageLayer;

>>

>>   import com.vividsolutions.jts.geom.Envelope;

>> +import com.vividsolutions.jts.geom.Geometry;

>>   import com.vividsolutions.jump.I18N;

>>   import com.vividsolutions.jump.feature.Feature;

>>   import com.vividsolutions.jump.feature.FeatureCollection;

>> +import 

Re: [JPP-Devel] Invalid GeoJSON if no attributes

[edgar . soldin]

Jukka,

please try r5188.. ede

On 15.11.2016 10:31, edgar.sol...@web.de wrote:
> from http://geojson.org/geojson-spec.html
> "
> A GeoJSON object with the type "Feature" is a feature object.
> 
> A feature object must have a member with the name "geometry". The value of 
> the geometry member is a geometry object as defined above or a JSON null 
> value.
> 
> A feature object must have a member with the name "properties". The value of 
> the properties member is an object (any JSON object or a JSON null value).
> "
> 
> so that means 
>"properties": null
> which validates on http://geojsonlint.com/
> 
> will fix it, did you came across a parser that did not like OJ generated 
> GeoJSON because of that?
> 
> ..ede
> On 15.11.2016 09:57, Rahkonen Jukka (MML) wrote:
>> Hi,
>>
>> In GeoJSON FeatureCollection must have "properties" member even if there are 
>> no attributes. This output from OpenJUMP r5186 does not validate
>>
>> {
>> "type": "FeatureCollection",
>>
>> "features": [
>> { "type": "Feature", "geometry": 
>> {"type":"Polygon","coordinates":[[[278,423],[483,505],[478,293],[278,423]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}}
>>  }
>> ]
>>
>> }
>>
>> I am not sure if this is the right fix but at least it validates:
>> { "type": "Feature", "properties": { }, "geometry": 
>>
>> It seems that GeoJSONLint http://geojsonlint.com/ does not like the crs 
>> member any more because it belongs to older, year 2008 version of GeoJSON.  
>> However, I think that OpenJUMP should still output the old version that 
>> supports projections. I try to find some more flexible validator.
>>
>> -Jukka Rahkonen-
>> --
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
> 
> --
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] SVN: [5188] core/trunk/src/com/vividsolutions/jump/io/geojson

[jump-pilot-svn]

Revision: 5188
  http://sourceforge.net/p/jump-pilot/code/5188
Author:   edso
Date: 2016-11-15 10:02:05 + (Tue, 15 Nov 2016)
Log Message:
---
GeoJSON spec expects properties object to written all the time, might be null 
though

Modified Paths:
--
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java

core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java

Modified: 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java
===
--- core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java 
2016-11-14 07:46:15 UTC (rev 5187)
+++ core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONConstants.java 
2016-11-15 10:02:05 UTC (rev 5188)
@@ -2,14 +2,17 @@
 
 public class GeoJSONConstants {
   public static final String CHARSET = "UTF-8";
-  
+
   public static final String PROPERTIES = "properties";
   public static final String GEOMETRY = "geometry";
   public static final String FEATURES = "features";
   public static final String TYPE = "type";
-  
+
   public static final String TYPE_FEATURE = "Feature";
   public static final String TYPE_FEATURECOLLECTION = "FeatureCollection";
-  
-  public static final String EMPTY_GEOMETRY = "\"geometry\": 
{\"type\":\"GeometryCollection\",\"geometries\":[]}";
+
+  // for performance reasons, prevent concatenating the same string
+  public static final String EMPTY_GEOMETRY = "\"" + GEOMETRY
+  + "\": {\"type\":\"GeometryCollection\",\"geometries\":[]}";
+  public static final String EMPTY_PROPERTIES = "\"" + PROPERTIES + "\" : 
null";
 }

Modified: 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java
===
--- 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java
  2016-11-14 07:46:15 UTC (rev 5187)
+++ 
core/trunk/src/com/vividsolutions/jump/io/geojson/GeoJSONFeatureCollectionWrapper.java
  2016-11-15 10:02:05 UTC (rev 5188)
@@ -319,13 +319,16 @@
 else
   geometryJson = GeoJSONConstants.EMPTY_GEOMETRY;
 
+// the GeoJSON specs expect properties to be written, it might be null 
when empty
 if (propertiesJson != null)
   propertiesJson = "\"" + GeoJSONConstants.PROPERTIES + "\": { "
   + propertiesJson + " }";
+else
+  propertiesJson = GeoJSONConstants.EMPTY_PROPERTIES;
 
 return "{ \"" + GeoJSONConstants.TYPE + "\": \""
 + GeoJSONConstants.TYPE_FEATURE + "\""
-+ (propertiesJson != null ? ", " + propertiesJson : "")
-+ (geometryJson != null ? ", " + geometryJson : "") + " }";
++ ", " + propertiesJson
++ ", " + geometryJson;
   }
 }


--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Invalid GeoJSON if no attributes

[edgar . soldin]

from http://geojson.org/geojson-spec.html
"
A GeoJSON object with the type "Feature" is a feature object.

A feature object must have a member with the name "geometry". The value of the 
geometry member is a geometry object as defined above or a JSON null value.

A feature object must have a member with the name "properties". The value of 
the properties member is an object (any JSON object or a JSON null value).
"

so that means 
   "properties": null
which validates on http://geojsonlint.com/

will fix it, did you came across a parser that did not like OJ generated 
GeoJSON because of that?

..ede
On 15.11.2016 09:57, Rahkonen Jukka (MML) wrote:
> Hi,
> 
> In GeoJSON FeatureCollection must have "properties" member even if there are 
> no attributes. This output from OpenJUMP r5186 does not validate
> 
> {
> "type": "FeatureCollection",
> 
> "features": [
> { "type": "Feature", "geometry": 
> {"type":"Polygon","coordinates":[[[278,423],[483,505],[478,293],[278,423]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}}
>  }
> ]
> 
> }
> 
> I am not sure if this is the right fix but at least it validates:
> { "type": "Feature", "properties": { }, "geometry": 
> 
> It seems that GeoJSONLint http://geojsonlint.com/ does not like the crs 
> member any more because it belongs to older, year 2008 version of GeoJSON.  
> However, I think that OpenJUMP should still output the old version that 
> supports projections. I try to find some more flexible validator.
> 
> -Jukka Rahkonen-
> --
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> 

--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Invalid GeoJSON if no attributes

[Rahkonen Jukka (MML)]

Hi,

In GeoJSON FeatureCollection must have "properties" member even if there are no 
attributes. This output from OpenJUMP r5186 does not validate

{
"type": "FeatureCollection",

"features": [
{ "type": "Feature", "geometry": 
{"type":"Polygon","coordinates":[[[278,423],[483,505],[478,293],[278,423]]],"crs":{"type":"name","properties":{"name":"EPSG:0"}}}
 }
]

}

I am not sure if this is the right fix but at least it validates:
{ "type": "Feature", "properties": { }, "geometry": 

It seems that GeoJSONLint http://geojsonlint.com/ does not like the crs member 
any more because it belongs to older, year 2008 version of GeoJSON.  However, I 
think that OpenJUMP should still output the old version that supports 
projections. I try to find some more flexible validator.

-Jukka Rahkonen-
--
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

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

[Michaël Michaud]

Hi,

If I had to refactor the layer hierarchy to include datasets without 
geometry, I would probably try something like that
(note that it would be a big refactoring, and I am not able to evaluate 
the workload to achieve it)


Current layer hierarchy

Current layer hierarchy

Proposition to include non-geometric data (and to factorize some attributes)


Proposed layer hierachy
Le 14/11/2016 à 14:29, Stefan Steiniger a écrit :


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 better idea about the possibility to throw out 
the geom.


cheers,

stefan

-- Originalnachricht --
*Von: *
*Datum: *14.11.2016 9:45
*An: *OpenJump develop and use;
*Betreff:*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 some exceptions here and there, 
as OJ expects geometries in featurecollections, but apart from that it would be 
clean and the renderer would not need to monitor geom changes at all.

..ede

On 14.11.2016 10:39, Giuseppe Aruta wrote:
> 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 instance loading
> .csv on auto mode) as tables (I already added added into Sextante binding a
> Boolean method that allows to decode these files).
> I wondered if users would also have benefit  to visualize that a table is
> loaded into OJ workbench, with a table icon.
> I will check other solutions. Thanks for the hint.
> Peppe
>
> Il 13/Nov/2016 23:21, "Michaël Michaud"ha > scritto: > >> Hi Peppe, >> >> Seel also my answer on 2016-10-29. 
>> >> TreeLayerNamePanel has a listener, but to avoid a 
featureCollection scan >> after each change >> you probably need to 
keep a cache in the Layer as suggested by Ede, and >> use the Layer's 
>> listener to update the cache every time a feature is added, removed 
or >> changed >> >> Michaël >> >> >> Le 13/11/2016 à 19:51, 
edgar.sol...@web.de a écrit : >>> thanks.. how about implementing the 
caching/listener approach if you >> like to have icon? ..ede >>> >>> 
On 13.11.2016 18:57, Giuseppe Aruta wrote:  Ok Ede, I didn't  know 
it. I will revert the change.  Thanks again  Peppe   
Il 13/Nov/2016 18:48, ha scritto:  > Peppe, > > NACK.. 
this is going to get very slow for huge datasets containing >> empty 
> geoms only, as it is run on every redraw of the layer tree. 
please >> cache > the state and use a layer change listener or 
else users will complain >> about > a frozen OJ some time in the 
future and we will have a hard time to > pinpoint the reason, 
again ;) > > ..ede > > On 13.11.2016 18:41, 
jump-pilot-...@lists.sourceforge.net wrote: >> Revision: 5185 
>>http://sourceforge.net/p/jump-pilot/code/5185 >> 
Author:   ma15569 >> Date: 2016-11-13 17:41:37 + (Sun, 13 
Nov 2016) >> Log Message: >> --- >> The layer tree 
shows a table icon for layers that have features with > empty 
geometries >> Modified Paths: >> -- >> 
 core/trunk/src/com/vividsolutions/jump/workbench/ > 
ui/LayerNameRenderer.java >> Modified: 
core/trunk/src/com/vividsolutions/jump/workbench/ > 
ui/LayerNameRenderer.java >> 
=== 
>> --- core/trunk/src/com/vividsolutions/jump/workbench/ >> 
ui/LayerNameRenderer.java >2016-11-13 17:21:20 UTC (rev 
5184) >> +++ core/trunk/src/com/vividsolutions/jump/workbench/ >> 
ui/LayerNameRenderer.java >2016-11-13 17:41:37 UTC (rev 
5185) >> @@ -36,6 +36,7 @@ >>   import java.awt.Rectangle; 
>>   import java.io.File; >>   import java.util.Iterator; 
>> +import java.util.List; >> >>   import 
javax.swing.DefaultListCellRenderer; >>   import javax.swing.Icon; 
>> @@ -54,9 +55,11 @@ >>   import 
org.openjump.core.rasterimage.RasterImageLayer; >> >>   import 
com.vividsolutions.jts.geom.Envelope; >> +import 
com.vividsolutions.jts.geom.Geometry; >>   import 
com.vividsolutions.jump.I18N; >>   import 
com.vividsolutions.jump.feature.Feature; >>   import 
com.vividsolutions.jump.feature.FeatureCollection;