date:20200929



Hi Jukka,wrt. z/m reading, the patch I had submitted to JTS has been included in locationtech repo just before the 1.5 release. So you're right, with our 1.14 vividsolutions version, we probably can't read both forms of WKB. Hopefully, it will be easier after our migration to OJ 2.0.Michaëlenvoyé : 29 septembre 2020 à 17:34de : "Rahkonen Jukka (MML)" à : OpenJump develop and use , Larry Reeder objet : Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DSHi,Michaël must remember this better, but JTS did not understand the ISO codes for 3 and 4 dimensional geometries. This is probably fixed in the locationtech version. See https://lists.osgeo.org/pipermail/geos-devel/2013-December/006757.htmlSo it may be that once we move to GitHub and to new JTS version, and DB Query plugin gets possible fixes needed for the new JTS, it just starts to work with XYZ(M) geometries. Until that those who know can cast geometries into XY with SQL.-Jukka--Jukka Rahkonen--Alkuperäinen viesti-Lähettäjä: edgar.sol...@web.de  Lähetetty: tiistai 29. syyskuuta 2020 17.36Vastaanottaja: jump-pilot-devel@lists.sourceforge.net; Larry Reeder Aihe: Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DSOn 28.09.2020 21:46, Rahkonen Jukka (MML) wrote:We have the robust DB Query that works fine (despite with XYZ geometries but that's another thing).yeah, noticed that DBQuery choked on some geometries from a gpkg test file.Jukka, would you mind providing some test files for geometry blobs that currently don't work with DBQuery so we can ask Larry to enhance the extension? i'll cc him, so Larry, if you're not interested to maintain it anymore please speak up :)thx.. ede___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jump-pilot-devel___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://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] Run datastore query too tied to schema with Spatialide DS

On 29.09.2020 19:45, Rahkonen Jukka (MML) wrote:
> select AsGPB(casttoxy(castautomagic(geom))) from test limit 1;

right

select casttoxy(castautomagic(geom)) from random_points

works for my test gpkg data set. wrt. DBQuery

..ede


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

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

Hi,

Michaël must remember this better, but JTS did not understand the ISO codes for 
3 and 4 dimensional geometries. This is probably fixed in the locationtech 
version. See 
https://lists.osgeo.org/pipermail/geos-devel/2013-December/006757.html

So it may be that once we move to GitHub and to new JTS version, and DB Query 
plugin gets possible fixes needed for the new JTS, it just starts to work with 
XYZ(M) geometries. Until that those who know can cast geometries into XY with 
SQL.

-Jukka-

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: edgar.sol...@web.de  
Lähetetty: tiistai 29. syyskuuta 2020 17.36
Vastaanottaja: jump-pilot-devel@lists.sourceforge.net; Larry Reeder 

Aihe: Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

On 28.09.2020 21:46, Rahkonen Jukka (MML) wrote:
> We have the robust DB Query that works fine (despite with XYZ geometries but 
> that's another thing).

yeah, noticed that DBQuery choked on some geometries from a gpkg test file.

Jukka, would you mind providing some test files for geometry blobs that 
currently don't work with DBQuery so we can ask Larry to enhance the extension? 
i'll cc him, so Larry, if you're not interested to maintain it anymore please 
speak up :)

thx.. 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] 6506 loading raster test

2020-09-29 Thread Roberto Rossi

Il 29/09/2020 15:00, edgar.sol...@web.de ha scritto:

Rob,

does that happen with all files or can you pinpoint a specific layer/image?

Ede,
I noticed it for the continuos raster ad Digital terrain models (DTM),
slope, hillshade.

Rob

@Peppe: any idea? ..ede

On 9/24/2020 18:37, Roberto Rossi wrote:

Hi Ede,
I tested the release 6530

Now there is no any problem in loading the raster file (TIF).
But there is new problem in visualization.
After having loaded several rasters (or the big shapefiles and a few raster), the files begin
to be visualized like in the discrete rendering option in ArcGIS
(cit.
/"//Applies a new color for each unique value until you reach the //Number of
colors//specified; then the unique value starts at the beginning of the color scheme until it
reaches the //Number of colors//specified again. This rendering process continues until all the
unique values have been displayed. This is helpful for rasters with a lot of unique values,
where you do not need a legend"/)
On the a DTM, on the left the correct visualization, on the right the wrong one.

I noticed that if you remove the big shapefiles (and free memory) you're able
to visualize correctly the DTM again (openjump2.log).

Thank you again

Rob

Il 23/09/2020 18:57, edgar.sol...@web.de ha scritto:

hey Rob,

actually it's Edgar but call me ede ;9

anyway, please try snapshot r6526 and come back with results. thx! ..ede

On 9/22/2020 23:34, Roberto Rossi wrote:

Hello Edgard,
i repeated the test with the "-v trace" option... the log is really verbose
now: from 50 to 15000 kb! :-)

I tried at first to load the shapefiles
, the
error raised at the 7th raster

loaded.
You can find documentation in the /openjump1.log
/

Loading the rasters
altogether:
I had the error loading one of the last rasters; you can find documentation in the
/openjump2.log/
/
/

Here you can find the log files

/
/
/Thank you
/

Roberto

Il 22/09/2020 15:44, edgar.sol...@web.de ha scritto:

hey Roberto,

the verbosity setting was just added to the start scripts, so it is not
actually documented yet. looks like your on windows.

on windows
edit 'bin/oj_windows.bat'

find

rem -- set some default OJ options here (eg. -v debug), initialize empty --
rem -- run OJ with '--help' argument to find out which are available --
set JUMP_OPTS=

change it to it to

rem -- set some default OJ options here (eg. -v debug), initialize empty --
rem -- run OJ with '--help' argument to find out which are available --
set "JUMP_OPTS=-v trace"

NOTE the double quotes around the whole assignment. this will make OJ somewhat
slower, so you might want to leave it deactivated in production.

for linux/macos you will find the same setting in 'bin/oj_linux.sh'

## uncomment and edit if you want some default OJ parameter set
## run OJ with '--help' argument to find out which are available
#JUMP_OPTS="-v DEBUG"

where you need to uncomment it and change it to trace.

can you please redo your tests as without proper error stacks the logs are not
helpful at all ;) .. thx! ede

On 9/21/2020 23:34, Roberto Rossi wrote:

Hello,
tank you for the big effort in developing this powerful software!

I just tested the 6506 release.
(I wasn't able to use "-v trace": where should I set this option, or where can
I find instructions?)

I tried at first to load 2 shapefiles
, and
then one the raster you can find here.

I had the yellow band error /(Array Index Out Of Bounds Exception)/: you can
find documentation in the /openjump1.log
/

I turn off and executed again openjump. I loaded the rasters
altogether:
I had the error after about half rasters where loaded: you can find documentation in the
/openjump2.log/
/
/
I don't have the same problems with the 1.15 release/
/

Roberto Rossi

Il 21/09/2020 18:31, edgar.sol...@web.de ha scritto:

On 21.09.2020 17:19, Giuseppe Aruta wrote:

Hi Ede,
it works fine. I was able to cut a selected part of the image. And also I
tested on some simple tools form Sextante that generate raster (Rasterize a
vector layer, change no data value..).
Let us wait for Roberto's test. I think

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

On 28.09.2020 21:46, Rahkonen Jukka (MML) wrote:
> We have the robust DB Query that works fine (despite with XYZ geometries but 
> that's another thing).

yeah, noticed that DBQuery choked on some geometries from a gpkg test file.

Jukka, would you mind providing some test files for geometry blobs that 
currently don't work with DBQuery so we can ask Larry to enhance the extension? 
i'll cc him, so Larry, if you're not interested to maintain it anymore please 
speak up :)

thx.. ede

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

Re: [JPP-Devel] 6506 loading raster test

Rob,

does that happen with all files or can you pinpoint a specific layer/image?

@Peppe: any idea? ..ede

On 9/24/2020 18:37, Roberto Rossi wrote:
> Hi Ede,
> I tested the release 6530
>
> Now there is no any problem in loading the raster file (TIF).
> But there is new problem in visualization.
> After having loaded several rasters (or the big shapefiles and a few raster), 
> the files begin to be visualized like in the discrete rendering option in 
> ArcGIS 
> (cit.
>  /"//Applies a new color for each unique value until you reach the //Number 
> of colors//specified; then the unique value starts at the beginning of the 
> color scheme until it reaches the //Number of colors//specified again. This 
> rendering process continues until all the unique values have been displayed. 
> This is helpful for rasters with a lot of unique values, where you do not 
> need a legend"/)
> On the a DTM, on the left the correct visualization, on the right the wrong 
> one.
>
>
>
> I noticed that if you remove the big shapefiles (and free memory) you're able 
> to visualize correctly the DTM again (openjump2.log).
>
> Thank you again
>
>     Rob
>
>
> Il 23/09/2020 18:57, edgar.sol...@web.de ha scritto:
>> hey Rob,
>>
>> actually it's Edgar but call me ede ;9
>>
>> anyway, please try snapshot r6526 and come back with results. thx! ..ede
>>
>> On 9/22/2020 23:34, Roberto Rossi wrote:
>>> Hello Edgard,
>>> i repeated the test with the "-v trace" option... the log is really verbose 
>>> now: from 50 to 15000 kb! :-)
>>>
>>> I tried at first to load the shapefiles 
>>> ,
>>>  the error raised at the 7th raster 
>>> 
>>>  loaded.
>>> You can find documentation in the /openjump1.log
>>> /
>>>
>>> Loading the rasters 
>>> altogether:
>>>  I had the error loading one of the last rasters; you can find 
>>> documentation in the /openjump2.log/
>>> /
>>> / 
>>> 
>>> Here you can find the log files 
>>> 
>>> /
>>> /
>>> /Thank you
>>> /
>>>
>>> Roberto
>>>
>>> Il 22/09/2020 15:44, edgar.sol...@web.de ha scritto:
 hey Roberto,

 the verbosity setting was just added to the start scripts, so it is not 
 actually documented yet. looks like your on windows.

 on windows
 edit 'bin/oj_windows.bat'

 find

 rem -- set some default OJ options here (eg. -v debug), initialize empty --
 rem -- run OJ with '--help' argument to find out which are available --
 set JUMP_OPTS=

 change it to it to

 rem -- set some default OJ options here (eg. -v debug), initialize empty --
 rem -- run OJ with '--help' argument to find out which are available --
 set "JUMP_OPTS=-v trace"

 NOTE the double quotes around the whole assignment. this will make OJ 
 somewhat slower, so you might want to leave it deactivated in production.

 for linux/macos you will find the same setting in 'bin/oj_linux.sh'

 ## uncomment and edit if you want some default OJ parameter set
 ## run OJ with '--help' argument to find out which are available
 #JUMP_OPTS="-v DEBUG"

 where you need to uncomment it and change it to trace.

 can you please redo your tests as without proper error stacks the logs are 
 not helpful at all ;) .. thx! ede


 On 9/21/2020 23:34, Roberto Rossi wrote:
> Hello,
> tank you for the big effort in developing this powerful software!
>
> I just tested the 6506 release.
> (I wasn't able to use "-v trace": where should I set this option, or 
> where can I find instructions?)
>
> I tried at first to load 2 shapefiles 
> ,
>  and then one the raster you can find here. 
> 
> I had the yellow band error /(Array Index Out Of Bounds Exception)/: you 
> can find documentation in the /openjump1.log
> /
>
> I turn off and executed again openjump. I loaded the rasters 
> altogether:
>  I had the error after about half rasters where loaded: you can find 
> documentation in the /openjump2.log/
> /
> /
> I don't have the same problems with the 1.15 release/
> /
>
> Roberto Rossi
>
> Il

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

2020-09-29 Thread jump-pilot-svn--- via Jump-pilot-devel

On 9/29/2020 14:22, Michaud Michael wrote:
> Ede,
>
>
> OJ can't support multiple geometries and it would be a difficult task to make
> this change.
>
>  >well, in theory it can. the model as is merely limits geometry to be _only
> one_ of the attributes. as Geometry is a proper attribute type we can easily 
> add
> more than one, they won't be displayed though ;)
>
> Actually, FeatureSchema.addAttribute check that no Geometry geometryIndex is 
> -1
> (and set geometryIndex to a index > -1 if non exist).

not saying there are no obstacles. just saying there is nothing that prevents 
us from implementing it.

> Object type can be used
>
> how about a new BLOB attribute type, signifying that the column contains plain
> bytes, in case blobs are delivered by the underlying data reader?
>
> What would be the advantage over Object ?

your mail quoting seems to be broken agn ;9

the advantage would be the explicit typed binary nature, while for an Object we 
do not know how the attribute backend handles it internally. actually afaics we 
use Object if we get something from a data source that does not match a known 
data type.

> - to preserve original data as much as possible, but will generally not 
> survive
> a complete roundtrip (maybe a more specific serialization format could achieve
> this goal, but with format like shapefile, we will rapidly encounter the 255
> char problem).
>
> if it is not saveable w/o data loss the write should simply err out and give 
> the
> user a chance to save it another way. as much as i understand the industry
> standardness of the shapefile format, we shouldn't strive to make it limiting
> factor for OJ data formats.
>
> I think that in most drivers, Object type is converted to String with 
> toString()
> method, which is not so bad.

well, it's bad in case of BLOBs

> Probably a warning would be appreciated. Error would
> probably force the user to remove the column before saving without offering
> better alternative.

or saving to another format or converting the blob into WKT and save that to 
CSV. the possibilities are endless :))

> - to offer plugin developpers a way to store structured data for in-memory 
> usage
> (e.g. multiscale display as suggested by Jukka). I'm not aware of a concrete
> use-case though.
>
> watcha mean by "structured data for in-memory usage" ?.. ede
>
> E.g. computing different simplified geometries for different scale 
> representoins
> in named attributes g1, g2, g3. Could not be saved in file, but could be used 
> by
> a plugin aware of these attributes and avoid on the fly computation. Could 
> also
> read image from a read-only database to display it on screen... Not sure these
> example are relevant, just ideas.

ic. yeah let's table that thought. i'm merely interested in not destroying 
additional geometry columns in datasets or at least warn that they are there or 
ignore them with a warning, so the user dosn't get a chance to corrupt them, if 
that makes sense.

..ede


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

[JPP-Devel] SVN: [6557] core/trunk/src/org/openjump/core/ui/plugin/tools/generate/ RasterizePlugIn.java

Revision: 6557
  http://sourceforge.net/p/jump-pilot/code/6557
Author:   ma15569
Date: 2020-09-29 12:28:03 + (Tue, 29 Sep 2020)
Log Message:
---
Added other options. Saved cell size on output

Modified Paths:
--

core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java

Modified: 
core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java
===
--- 
core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java  
2020-09-29 12:18:07 UTC (rev 6556)
+++ 
core/trunk/src/org/openjump/core/ui/plugin/tools/generate/RasterizePlugIn.java  
2020-09-29 12:28:03 UTC (rev 6557)
@@ -31,6 +31,7 @@
 import javax.swing.JComponent;
 import javax.swing.JFileChooser;
 import javax.swing.JLabel;
+import javax.swing.JOptionPane;
 import javax.swing.JPanel;
 import javax.swing.JTextField;
 
@@ -49,6 +50,7 @@
 import com.vividsolutions.jump.task.TaskMonitor;
 import com.vividsolutions.jump.util.FileUtil;
 import com.vividsolutions.jump.workbench.JUMPWorkbench;
+import com.vividsolutions.jump.workbench.Logger;
 import com.vividsolutions.jump.workbench.WorkbenchContext;
 import com.vividsolutions.jump.workbench.model.Category;
 import com.vividsolutions.jump.workbench.model.Layer;
@@ -69,7 +71,6 @@
 import com.vividsolutions.jump.workbench.ui.Viewport;
 import com.vividsolutions.jump.workbench.ui.images.IconLoader;
 
-import de.latlon.deejump.wfs.jump.WFSLayer;
 import it.betastudio.adbtoolbox.libs.FileOperations;
 
  
@@ -79,11 +80,10 @@
 
private Layer sourceLayer;
private JTextField cellYextFiels;
-   private JCheckBox externalLayerCheck;
-   private JComboBox layerableComboBox;
-   private JComboBox   selectLayerComboBox;
-private JComboBox jcb_attribute;
-private LayerNameRenderer layerListCellRenderer = new 
LayerNameRenderer();
+   private JCheckBox externalLayerCheck,expandCheck, loadCheck;
+   private JComboBox layerableComboBox, selectLayerComboBox;
+   private JComboBox jcb_attribute;
+   private LayerNameRenderer layerListCellRenderer = new 
LayerNameRenderer();
   
  private static String selAttribute = null;
private String ATTRIBUTE = GenericNames.SELECT_ATTRIBUTE;
@@ -108,6 +108,15 @@
private final static String USE_EXTERNAL_EXTENT = 
I18N.get("ui.plugin.tools.generate.RasterizePlugIn.use-extent");
private final static String DESCRIPTION = 
I18N.get("ui.plugin.tools.generate.RasterizePlugIn.description");
 
+   //TODO internationalize
+   private final static String EXPAND_ONE_CELL = "Expand one cell size 
to each direction";
+   private final static String EXPAND_ONE_CELL_TIP = "It expands the 
extension layer but can generate area of no data at the border";
+   private final static String LOAD_RASTER_INTO_VIEW = "Load ouput 
raster into the view";
+   
+   private final static String sSaved = I18N
+   
.get("org.openjump.core.ui.plugin.raster.RasterImageLayerPropertiesPlugIn.file.saved");
+   private final static String SCouldNotSave = I18N
+   
.get("org.openjump.sextante.gui.additionalResults.AdditionalResultsPlugIn.Could-not-save-selected-result");
@Override
   public boolean execute(PlugInContext context) throws Exception {
MultiInputDialog dialog = new MultiInputDialog(
@@ -188,6 +197,8 @@
 layerableComboBox.setEnabled(false);
 layerableComboBox.setSize(240,
 layerableComboBox.getPreferredSize().height);
+expandCheck=dialog.addCheckBox(EXPAND_ONE_CELL, false, 
EXPAND_ONE_CELL_TIP);
+expandCheck.setEnabled(false);
 selectLayerComboBox.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
@@ -195,6 +206,7 @@
.filter(dialog.getLayer(SOURCE_LAYER));
   jcb_attribute.setModel(new DefaultComboBoxModel<>(list
.toArray(new String[0])));
+  expandCheck.setEnabled(externalLayerCheck.isSelected());
}
  });
 externalLayerCheck.addActionListener(new ActionListener() {
@@ -205,7 +217,8 @@
  });
   //[Giuseppe Aruta 2020-09-27] deactivated. As suggested by Roberto Rossi
  //It is better to leave a standard value for cell that user can 
modified
- /*   layerableComboBox.addActionListener(new ActionListener() {
+ // [Giuseppe Aruta 2020-09-29]  reactivated
+   layerableComboBox.addActionListener(new ActionListener() {
@Override
public void

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

2020-09-29 Thread jump-pilot-svn--- via Jump-pilot-devel



Ede,OJ can't support multiple geometries and it would be a difficult task to makethis change.>well, in theory it can. the model as is merely limits geometry to be _only one_ of the attributes. as Geometry is a proper attribute type we can easily add more than one, they won't be displayed though ;)Actually, FeatureSchema.addAttribute check that no Geometry geometryIndex is -1 (and set geometryIndex to a index > -1 if non exist).Object type can be usedhow about a new BLOB attribute type, signifying that the column contains plain bytes, in case blobs are delivered by the underlying data reader?What would be the advantage over Object ?- to preserve original data as much as possible, but will generally not survivea complete roundtrip (maybe a more specific serialization format could achievethis goal, but with format like shapefile, we will rapidly encounter the 255char problem).if it is not saveable w/o data loss the write should simply err out and give the user a chance to save it another way. as much as i understand the industry standardness of the shapefile format, we shouldn't strive to make it limiting factor for OJ data formats.I think that in most drivers, Object type is converted to String with toString() method, which is not so bad.Probably a warning would be appreciated. Error would probably force the user to remove the column before saving without offering better alternative.- to offer plugin developpers a way to store structured data for in-memory usage(e.g. multiscale display as suggested by Jukka). I'm not aware of a concreteuse-case though.watcha mean by "structured data for in-memory usage" ?.. edeE.g. computing different simplified geometries for different scale representoins in named attributes g1, g2, g3. Could not be saved in file, but could be used by a plugin aware of these attributes and avoid on the fly computation. Could also read image from a read-only database to display it on screen... Not sure these example are relevant, just ideas.Michaël___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://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: [6556] core/trunk/src/org/openjump/core/rasterimage/algorithms/ RasterizeAlgorithm.java

Revision: 6556
  http://sourceforge.net/p/jump-pilot/code/6556
Author:   ma15569
Date: 2020-09-29 12:18:07 + (Tue, 29 Sep 2020)
Log Message:
---
Recalculate cols and rows to avoid resampling of cell size

Modified Paths:
--

core/trunk/src/org/openjump/core/rasterimage/algorithms/RasterizeAlgorithm.java

Modified: 
core/trunk/src/org/openjump/core/rasterimage/algorithms/RasterizeAlgorithm.java
===
--- 
core/trunk/src/org/openjump/core/rasterimage/algorithms/RasterizeAlgorithm.java 
2020-09-28 13:06:25 UTC (rev 6555)
+++ 
core/trunk/src/org/openjump/core/rasterimage/algorithms/RasterizeAlgorithm.java 
2020-09-29 12:18:07 UTC (rev 6556)
@@ -261,6 +261,11 @@
   double maxY = limitEnvelope.getMaxY();
   m_Extent.setXRange(minX, maxX);//limitEnvelope.getMaxX());
   m_Extent.setYRange(minY, maxY);//limitEnvelope.getMaxY()); 
+  minX = m_Extent.getXMin();
+  minY = m_Extent.getYMin();
+   maxX = m_Extent.getXMax();
+  maxY = m_Extent.getYMax();
+  //Recalculate cols and rows to avoid resampling of cell size
   m_iNX = m_Extent.getNX();
   m_iNY = m_Extent.getNY(); 
  double[][] valori= new double[m_iNX][m_iNY];



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

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

On 9/29/2020 13:00, Michaud Michael wrote:
> Hi,
>
> OJ can't support multiple geometries and it would be a difficult task to make
> this change.

well, in theory it can. the model as is merely limits geometry to be _only one_ 
of the attributes. as Geometry is a proper attribute type we can easily add 
more than one, they won't be displayed though ;)

> Object type can be used

how about a new BLOB attribute type, signifying that the column contains plain 
bytes, in case blobs are delivered by the underlying data reader?

> - to preserve original data as much as possible, but will generally not 
> survive
> a complete roundtrip (maybe a more specific serialization format could achieve
> this goal, but with format like shapefile, we will rapidly encounter the 255
> char problem).

if it is not saveable w/o data loss the write should simply err out and give 
the user a chance to save it another way. as much as i understand the industry 
standardness of the shapefile format, we shouldn't strive to make it limiting 
factor for OJ data formats.

> - to offer plugin developpers a way to store structured data for in-memory 
> usage
> (e.g. multiscale display as suggested by Jukka). I'm not aware of a concrete
> use-case though.

watcha mean by "structured data for in-memory usage" ?.. ede

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

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS



Hi,OJ can't support multiple geometries and it would be a difficult task to make this change.Object type can be used- to preserve original data as much as possible, but will generally not survive a complete roundtrip (maybe a more specific serialization format could achieve this goal, but with format like shapefile, we will rapidly encounter the 255 char problem).- to offer plugin developpers a way to store structured data for in-memory usage (e.g. multiscale display as suggested by Jukka). I'm not aware of a concrete use-case though.Michaëlenvoyé : 29 septembre 2020 à 12:30de : edgar.sol...@web.deà : jump-pilot-devel@lists.sourceforge.netobjet : Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DSOn 9/29/2020 12:14, Rahkonen Jukka (MML) wrote:edgar.sol...@web.de wrote:29.9. 2020 13.01On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:>>> select geom,>>> ST_AsText(ST_Centroid(geom)) as centroid from test limit 1; >> do we currently warn/err out if someone actually selects two geometry columns? should we auto-convert to WKT additional geometry columns?The above query without ST_AsText gives me a field with datatype "Object" and it contains value [B@11031df7that's because everything without datatype is loaded as Object type, which default attrib representation is a simpy toString(), which "surprise" works well with Strings ;)Perhaps it is good so? I have no idea about what to do with such object and if it round trips nicely in save-reload cycle with our supported file formats. I guess that object could as well be a jpeg image or any other blob.yeah, more thinking of applying the blob-autodetecting here, in case we come around to it. keep in mind, we are talking merely representation in the attrib table. it'd be still backed by the blob based Object. and you are are right the question remains, how our writers/readers handle blobs, especially those that are text based (like GeoJSON). sure we could base64 encode it or such, but what i am saying is, i'm pretty sure it currently will blow up ;)..ede___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://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] Run datastore query too tied to schema with Spatialide DS



Hi,>>what about the multiple geometry column issue? what would be a use case 
for that and how would you suggest to present those in OJ? ..edeFor postgis, as far as I remember, we read the first geometry column as geometry and following geometry columns as String or Object (don't remember).In the RunQueryPlugin, if I need the second geometry column of a table having geom1, geom2, I write :select geom2 as geom, * from table(or the exact list of columns to avoid duplication of geom2 column)Michaëlenvoyé : 29 septembre 2020 à 10:57de : edgar.sol...@web.deà : jump-pilot-devel@lists.sourceforge.netobjet : Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DSmorning Jukka,On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:>> There would be still some corner cases left (select geom as geometry1, ST_Centroid(geom) as geometry2...in theory our features may hold multiple geometries. just one can be shown though and the second would be like some object attribute. not sure what'd be a use case for that.what about the multiple geometry column issue? what would be a use case for that and how would you suggest to present those in OJ? ..ede___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://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] Run datastore query too tied to schema with Spatialide DS

On 9/29/2020 12:14, Rahkonen Jukka (MML) wrote:
> edgar.sol...@web.de wrote:
> 29.9. 2020 13.01
>
> On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>>> select geom,
>>> ST_AsText(ST_Centroid(geom)) as centroid from test limit 1;
>
>> do we currently warn/err out if someone actually selects two geometry 
>> columns? should we auto-convert to WKT additional geometry columns?
>
> The above query without ST_AsText gives me a field with datatype "Object" and 
> it contains value [B@11031df7

that's because everything without datatype is loaded as Object type, which 
default attrib representation is a simpy toString(), which "surprise" works 
well with Strings ;)

> Perhaps it is good so? I have no idea about what to do with such object and 
> if it round trips nicely in save-reload cycle with our supported file 
> formats. I guess that object could as well be a jpeg image or any other blob.

yeah, more thinking of applying the blob-autodetecting here, in case we come 
around to it. keep in mind, we are talking merely representation in the attrib 
table. it'd be still backed by the blob based Object. and you are are right the 
question remains, how our writers/readers handle blobs, especially those that 
are text based (like GeoJSON). sure we could base64 encode it or such, but what 
i am saying is, i'm pretty sure it currently will blow up ;)

..ede

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

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

edgar.sol...@web.de wrote:
29.9. 2020 13.01

On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>> select geom,
>> ST_AsText(ST_Centroid(geom)) as centroid from test limit 1;

> do we currently warn/err out if someone actually selects two geometry 
> columns? should we auto-convert to WKT additional geometry columns? 

The above query without ST_AsText gives me a field with datatype "Object" and 
it contains value [B@11031df7
Perhaps it is good so? I have no idea about what to do with such object and if 
it round trips nicely in save-reload cycle with our supported file formats. I 
guess that object could as well be a jpeg image or any other blob.

-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] Run datastore query too tied to schema with Spatialide DS

On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>> morning Jukka,
>> On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
 There would be still some corner cases left (select geom as geometry1, 
 ST_Centroid(geom) as geometry2...
>>> in theory our features may hold multiple geometries. just one can be shown 
>>> though and the second would be like some object attribute. not sure what'd 
>>> be a use case for that.
>> what about the multiple geometry column issue? what would be a use case for 
>> that and how would you suggest to present those in OJ? ..ede
> Use cases that I know are like having cities as polygons and points for 
> rendering at different scales, or having accurate/generalized geometries for 
> the same purpose. The same result can be achieved by having multiple layers 
> though there is then unnecessary multiplication of attributes as well. I 
> would wait until someone presents a really cool use case and pull request 
> about multiple geometry fields in OpenJUMP. Until that I suppose people feel 
> happy if this works also in the future as it works now and saves processed 
> geometry as WKT into text field. Example tested with Spatialite
>
> select geom,
> ST_AsText(ST_Centroid(geom)) as centroid
> from test limit 1;

do we currently warn/err out if someone actually selects two geometry columns? 
should we auto-convert to WKT additional geometry columns? ..ede


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

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

edgar.sol...@web.de wrote
29.9. 2020 11.57

> morning Jukka,

> On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
>>> There would be still some corner cases left (select geom as geometry1, 
>>> ST_Centroid(geom) as geometry2...
>> in theory our features may hold multiple geometries. just one can be shown 
>> though and the second would be like some object attribute. not sure what'd 
>> be a use case for that.

> what about the multiple geometry column issue? what would be a use case for 
> that and how would you suggest to present those in OJ? ..ede

Use cases that I know are like having cities as polygons and points for 
rendering at different scales, or having accurate/generalized geometries for 
the same purpose. The same result can be achieved by having multiple layers 
though there is then unnecessary multiplication of attributes as well. I would 
wait until someone presents a really cool use case and pull request about 
multiple geometry fields in OpenJUMP. Until that I suppose people feel happy if 
this works also in the future as it works now and saves processed geometry as 
WKT into text field. Example tested with Spatialite

select geom, 
ST_AsText(ST_Centroid(geom)) as centroid
from test limit 1;

-Jukka-

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

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

morning Jukka,

On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
>> There would be still some corner cases left (select geom as geometry1, 
>> ST_Centroid(geom) as geometry2...
> in theory our features may hold multiple geometries. just one can be shown 
> though and the second would be like some object attribute. not sure what'd be 
> a use case for that.

what about the multiple geometry column issue? what would be a use case for 
that and how would you suggest to present those in OJ? ..ede


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

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS