[JPP-Devel] Select and delete raster image when opened by LoadRasterFile

[Giuseppe Aruta]

Hi all,
if I load a raster using OpenFilePlugIn (or OpenWizard not
AddRasterImageLayerWizard), than raster is opened as a vector file.
The curious situation is that user can  select raster on workbench (if edit
option is enabled on context menu) and I can delete it.
This behavior is not useful. User can use a raster file as a base map and,
if they are not aware,   they can delete raster and need to reload it again
when editing vector files.
One solution could be to deactivate edit/modify on loading image raster
regards

Peppe
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Enhancing DB Query Plugin with Spatialite functions.

[Rahkonen Jukka]

Larry Reeder wrote: 
 
> On Mon, Apr 8, 2013 at 1:03 PM,  wrote:
> On 08.04.2013 20:48, Michaël Michaud wrote:
>> > Just wanted to share this thought, but I admit that Spatialite is
> > a mature project which can add nice capabilities with a smaller
>> > effort.
>> ok, as far as i understand for now. DBQuery is working and in use. it uses 
>> native libs, but on the other hand we will probably not get this 
>> functionality going java only.
>> so, let's polish up native libs and DBQuery and consider to add it to PLUS 
>> after 1.6.0.
> 
> One clarification:   my plugin doesn't directly load native libraries.  It 
> uses the sqlite JDBC libraries, which handle the loading spatialite and other 
> sqllite extensions.   I also share some of the same concerns that Michaël 
> mentioned, and think that adding native libraries introduces risk and 
> complexity:
> 1.  A bug in the native libraries can cause the JVM to crash, taking down OJ 
> in the process (not just a stack trace but an outright crash.
> 2.  When done right, Java is write once, run everywhere.  With native libs, 
> you have to provide a library version for each platform you are deploying to: 
>  Windows 32bit/64bit, Linux 32/64, Mac OSX PowerPC/Intel, etc.
> 3. Regarding the spatialite lib, you not only need to include the correct 
> version of that, but the correct versions of everything it depends on, 
> including proj, geos, sqlite, and others. 
> 4.  Adding all these libs would reproduce in native code much of what OJ 
> already does in Java. 

Good analysis.  About 3), I use Spatialite myself very much and Spatialite 
versions and dependencies can make really bad problems.  the Sqlite database 
file holds only the data and some metadata.  All the intelligence is in the 
SQLite binaries and extensions.  I can easily create a Spatialite data file 
which is utilizing advanced features like views with reprojected geometries 
(=instruction to use Proj4 library for doing on-the-fly re-projecting), 
simplifield geometries (=instruction to use GEOS library for doing on-the-fly 
simplifying), virtual network for routing (needs Spatialite virtual network 
module).  However, if I send this database file to someone who has different 
binaries on his computer and compiled without Proj4, GEOS, Virtual network and 
others (or compiled with different version) he can't access these advanced 
features.  Spatialite is not always even backward compatible.  The only reason 
for me to accept all this mess is that Spatialite is so fast and works so well 
and when different computers and users have compatible binaries it is so handy 
to be able to copy and send the whole database with all the tables, views and 
indexes as a one single file.
 
>> Larry: would you be willing to accept patches on the regard above? would be 
>> a good opportunity to reuse a native lib loader that i created for the RXTX 
>> using gps extension originally.
> 
> Ede, I'm always open to new patches, I just  don't think a native lib loader 
> is needed due to SQLite JDBC handling the loading.
> Finally, the main purpose of the DBQuery plugin is to provide a bridge 
> between OJ and spatial databases that it might not support (if any now), as 
> well as provide a way to submit ad-hoc queries that don't have or need 
> backing tables to return features.  While I'm glad my recent changes make it 
> more useful for spatialite users, adding all the native libs to support 
> spatialite would weigh it very heavily toward the spatialite side.   If the 
> main goal is to improve spatialite, perhaps a better approach is to build up 
> the current sqlite/spatialite plugin to do so?

I agree.  DBQuery plugin is very robust because it does not try to be too 
clever. With Spatialite the robustness means that I can always read geometries 
and attributes from normal database tables and non-spatial attributes can be 
queried with SQL.  This covers actually most use cases even I may lose some 
views and other features.  The possibility to load Spatialite as extension is 
still a very good addition for advanced users.  It is probably best not to 
deliver any native binaries with the plugin and just mention where to get some 
tested ones. Perhaps you could still include the SQLite JDBC driver in the zip?

There is something that would perhaps need a patch and it is the "Unknown WKB 
type 0" problem.  Almost everything I find from the web with  that phrase seems 
to be related to OpenJUMP.  But is it so that others do not have similar 
problems with reading multigeometries from Spatialite than I do?

-Jukka Rahkonen-

>-lreeder
> 
> 
>> ..ede
> 
>

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free acc

[JPP-Devel] Raster Color Editor

[Giuseppe Aruta]

Hi,
as I can see on RasterColorEditor  trnsparency fro nodata values is
deactivated.
If I use sextante to generate DTM, defaut generated nodata value is
-9.0 which takes a dark black color on workbench, even when Raster
Color Editor is activated (to generate a range color values).
On my experience, on same raster, this dark color (nodata value from DTM)
cannot set to transparent even with original Raster Property menu from
Sextante contex menu.
Is there a solution that I don't know? As far as I remember
RasterColorEditor derives from original OJ The Merge. That Plugin was able
to set nodata values to transparent. But OJ the Merge was using a GDAL
bridge to load raster, which is quite different from Sextante (Pirol)
raster driver.

BTW: I have just given a look at OpenJUMP GDAL plugin documentation from
Erwan. that plugin was built using native Windows libraries but Erwan
didn't excude the possibility to build it on other (Linux, Mac) OS. This
opens many options to OJ considering how many things GDAL can do (but also
if it worth to embed at least other 100Mb of .dll/.so/.dylib native
libraries on PJ PLUS)

regards

peppe
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Select and delete raster image when opened by LoadRasterFile

[Rahkonen Jukka]

Hi,

The behaviour makes more sense if you consider that the image layer could be 
better called as Image catalog or Image index. The layer is not limited to 
contain only one image but you can add more images into the same layer with the 
Image Layer Manager tool. However, it does not really make much sense to remove 
the only image from the catalogue. Also the only reasonable thing that can be 
edited through the table view is to edit the image paths if files have been 
moved. Perhaps  editing of the image index layer should be possible to don only 
through the Image Layer Manager. However, it lacks the option to edit the file 
paths at the moment and if lots of images in the catalog have been moved it 
would be easier to edit them in the table view.

Add some more images into your image layer with Image Layer Manager, save the 
image layer as a vector layer in JUMP JML format, save and reopen the project 
and you will see how the image layer is planned to be utilized.
-Jukka Rahkonen-

Lähettäjä: Giuseppe Aruta [mailto:giuseppe_ar...@yahoo.it]
Lähetetty: 9. huhtikuuta 2013 10:31
Vastaanottaja: OpenJump develop and use
Aihe: [JPP-Devel] Select and delete raster image when opened by LoadRasterFile

Hi all,
if I load a raster using OpenFilePlugIn (or OpenWizard not  
AddRasterImageLayerWizard), than raster is opened as a vector file.
The curious situation is that user can  select raster on workbench (if edit 
option is enabled on context menu) and I can delete it.
This behavior is not useful. User can use a raster file as a base map and, if 
they are not aware,   they can delete raster and need to reload it again when 
editing vector files.
One solution could be to deactivate edit/modify on loading image raster
regards
Peppe
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Raster Profile tool

[Giuseppe Aruta]

Hi all,

raster profile tool is a very nice and useful tool. Thanks Stefan!
I wonder if it is possible, by the time that a profile is created, that the
tool remains active. So user can make multiple profiles (as a sort of INFO
raster tool) instead of activate the tool every times on menu

regards

Peppe
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] Raster Color Editor 2

[Giuseppe Aruta]

Hi all,
how Raster Color Editor defines how many intervals of color to apply to DTM?
Is it set to a defined number? If it is a fix interval number, Is it
possible to make user aware of this (example, instead to show "Raimbow", it
would be better "Raimbow (12 intervals)"?

regards

peppe
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] coordinate list NaN

[Uwe Dalluege]

Hi,

I think, the coordinate list shows wrong coordinates:

1. Draw a geometry.
2. Select with "Feature Info Tool" the geometry.
3. Switch to "HTML View"
The WKT and GML coordinates are all right
(two coordinates),
but CL shows three coordinates
with z-coordinate as NaN.

I think this is a little confusing
because the geometry has only two coordinates.

Uwe


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Enhancing DB Query Plugin with Spatialite functions.

[edgar . soldin]

On 09.04.2013 05:32, Larry Reeder wrote:
> 
> 
> 
> On Mon, Apr 8, 2013 at 1:03 PM,  > wrote:
> 
> On 08.04.2013 20:48, Michaël Michaud wrote:
> > Just wanted to share this thought, but I admit that Spatialite is
> > a mature project which can add nice capabilities with a smaller
> > effort.
> 
> ok, as far as i understand for now. DBQuery is working and in use. it 
> uses native libs, but on the other hand we will probably not get this 
> functionality going java only.
> so, let's polish up native libs and DBQuery and consider to add it to 
> PLUS after 1.6.0.
> 
> 
> One clarification:   my plugin doesn't directly load native libraries.  It 
> uses the sqlite JDBC libraries, which handle the loading spatialite and other 
> sqllite extensions.   

what about the mysql, oracle, postgis support .. doesn't it need native libs 
for these?

>I also share some of the same concerns that Michaël mentioned, and think that 
>adding native libraries introduces risk and complexity:
> 
> 1.  A bug in the native libraries can cause the JVM to crash, taking down OJ 
> in the process (not just a stack trace but an outright crash.

can happen

> 2.  When done right, Java is write once, run everywhere.  With native libs, 
> you have to provide a library version for each platform you are deploying to: 
>  Windows 32bit/64bit, Linux 32/64, Mac OSX PowerPC/Intel, etc.

well, yes and no. mostly yes, but lot's of specific quirks (starting the app, 
different implementations of system api functions) and let's not forget the 
classic *Whoops* the new jre has a bug that the old one hadn't .

> 3. Regarding the spatialite lib, you not only need to include the correct 
> version of that, but the correct versions of everything it depends on, 
> including proj, geos, sqlite, and others.

of course. still the functionality is there, so why not leverage it?

> 4.  Adding all these libs would reproduce in native code much of what OJ 
> already does in Java.

yes, it would blow up PLUS significantly. question is how much. i would make it 
depending on that.

> 
> Larry: would you be willing to accept patches on the regard above? would 
> be a good opportunity to reuse a native lib loader that i created for the 
> RXTX using gps extension originally.
> 
> 
> Ede, I'm always open to new patches, I just  don't think a native lib loader 
> is needed due to SQLite JDBC handling the loading.   

what about the other db's mentioned above? also it would ease the use of 
spatiallite as it could be found automagically and would not have to be 
specified in the url. same would go for users deciding they wanted to use the 
gdal lib support together with sqlite.

also, i'd anyway like to enhance the support for loading native code in OJ 
core. something along the lines that you just have to put it in 
lib/native/// or above if it works over several os versions 
and the setting up of native lib paths goes away.
 
> Finally, the main purpose of the DBQuery plugin is to provide a bridge 
> between OJ and spatial databases that it might not support (if any now), as 
> well as provide a way to submit ad-hoc queries that don't have or need 
> backing tables to return features.  While I'm glad my recent changes make it 
> more useful for spatialite users, adding all the native libs to support 
> spatialite would weigh it very heavily toward the spatialite side.   If the 
> main goal is to improve spatialite, perhaps a better approach is to build up 
> the current sqlite/spatialite plugin to do so?

i am no user, so i'd ask jukka. what do you think is the better starting point 
here?


..ede

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Enhancing DB Query Plugin with Spatialite functions.

[Rahkonen Jukka]

edgar soldin wrote:
 
> On 09.04.2013 05:32, Larry Reeder wrote:


> > One clarification:   my plugin doesn't directly load native libraries.  It 
> > uses
>> the sqlite JDBC libraries, which handle the loading spatialite and other 
>> sqllite
>> extensions.
> 
> what about the mysql, oracle, postgis support .. doesn't it need native libs 
> for
> these?

No, they are using the server-client architecture and it is enough to have a 
JDBC client which is written in Java for taking care about connecting to the 
port where the service is and discussion with the database by using the correct 
protocol.  SQLite is a different thing because there is no service to connect.  
The whole database engine is in the SQLite binaries. 
 
> >I also share some of the same concerns that Michaël mentioned, and think
> that adding native libraries introduces risk and complexity:
> >
> > 1.  A bug in the native libraries can cause the JVM to crash, taking down OJ
> in the process (not just a stack trace but an outright crash.
> 
> can happen
> 
> > 3. Regarding the spatialite lib, you not only need to include the correct
> version of that, but the correct versions of everything it depends on,
> including proj, geos, sqlite, and others.
> 
> of course. still the functionality is there, so why not leverage it?

It is possible to leverage it in such a way that if one dependency it broken 
then nothing works. Let's not do it that way. 
 
> > 4.  Adding all these libs would reproduce in native code much of what OJ
> already does in Java.
> 
> yes, it would blow up PLUS significantly. question is how much. i would make
> it depending on that.

This  depends on what is baked in with Spatialite. The dll package made by 
Alesssandro (Mr. Spatialite) contains mostly everything that is possible (GEOS, 
Proj4, iconv, Excel read stuff) and those make 11 MB all together in 10 dll 
files.  The SQLite JDBC driver which is compulsory makes 4 MB more.
I found also another build here 
https://bitbucket.org/mayastudios/files/src/9c048c2e9fcb/sqlite/sqlite-3.7.15.2/win-x86?at=default
Those two dll files (sqlite.dll and spatialite.dll) makeonly  5 MB together and 
they work OK with the DB Query plugin.  GEOS and Proj4 are included in the 
spatialite.dll in this build 
https://bitbucket.org/mayastudios/spatialite-lib-windows

I think that 9 or even 15 MB is not much for the coordinate system support 
alone.  But I do not know where to get binaries for all 
Windows/Linux/Mac/32-bit/64-bit.  I seems to be rather complicated to build 
Spatialite, especially for Windows.
 
> >
> > Larry: would you be willing to accept patches on the regard above? would
> be a good opportunity to reuse a native lib loader that i created for the RXTX
> using gps extension originally.
> >
> >
> > Ede, I'm always open to new patches, I just  don't think a native lib 
> > loader is
>> needed due to SQLite JDBC handling the loading.
> 
> what about the other db's mentioned above? also it would ease the use of
> spatiallite as it could be found automagically and would not have to be
> specified in the url. same would go for users deciding they wanted to use the
> gdal lib support together with sqlite.
 
If Spatialite is given in the URL then it is at least easy for the user to 
leave it out. I am not sure about what happens if loading of SQLite extension 
fails but I made a little test which suggests that if one part is missing then 
nothing works, not even standard functions which do not belong to the 
extension.  Therefore user should also have a possibility to skip extensions.
 
> also, i'd anyway like to enhance the support for loading native code in OJ
> core. something along the lines that you just have to put it in
> lib/native/// or above if it works over several os
> versions and the setting up of native lib paths goes away.
> 
> > Finally, the main purpose of the DBQuery plugin is to provide a bridge
>> between OJ and spatial databases that it might not support (if any now), as
>> well as provide a way to submit ad-hoc queries that don't have or need
>> backing tables to return features.  While I'm glad my recent changes make it
>> more useful for spatialite users, adding all the native libs to support 
>> spatialite
>> would weigh it very heavily toward the spatialite side.   If the main goal 
>> is to
>> improve spatialite, perhaps a better approach is to build up the current
>> sqlite/spatialite plugin to do so?
>> 
>> i am no user, so i'd ask jukka. what do you think is the better starting 
>> point
>> here?

Myself I will for sure use Spatialite extension with Larry's plugin but I 
consider that the plugin is pretty good as it is and I would not like to 
pollute it much with extra decorations.

-Jukka-

 
> 
> ..ede
> 
> --
> Precog is a next-generation analytics platform capable of advanced analytics
> on semi-structured data. The platform includes APIs for building apps and a
> 

Re: [JPP-Devel] Enhancing DB Query Plugin with Spatialite functions.

[edgar . soldin]

On 09.04.2013 15:33, Rahkonen Jukka wrote:
>>> Finally, the main purpose of the DBQuery plugin is to provide a bridge
>>> >> between OJ and spatial databases that it might not support (if any now), 
>>> >> as
>>> >> well as provide a way to submit ad-hoc queries that don't have or need
>>> >> backing tables to return features.  While I'm glad my recent changes 
>>> >> make it
>>> >> more useful for spatialite users, adding all the native libs to support 
>>> >> spatialite
>>> >> would weigh it very heavily toward the spatialite side.   If the main 
>>> >> goal is to
>>> >> improve spatialite, perhaps a better approach is to build up the current
>>> >> sqlite/spatialite plugin to do so?
>>> >> 
>>> >> i am no user, so i'd ask jukka. what do you think is the better starting 
>>> >> point
>>> >> here?
> Myself I will for sure use Spatialite extension with Larry's plugin but I 
> consider that the plugin is pretty good as it is and I would not like to 
> pollute it much with extra decorations.

Jukka: did you ever use the mentioned sqlite/spatialite plugin? is there such a 
thing?


..ede

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Enhancing DB Query Plugin with Spatialite functions.

[Rahkonen Jukka]

edgar soldin wrote:
> 
> On 09.04.2013 15:33, Rahkonen Jukka wrote:
> >>> Finally, the main purpose of the DBQuery plugin is to provide a
> >>> bridge
> >>> >> between OJ and spatial databases that it might not support (if
> >>> >> any now), as well as provide a way to submit ad-hoc queries that
> >>> >> don't have or need backing tables to return features.  While I'm
> >>> >> glad my recent changes make it more useful for spatialite users,
> adding all the native libs to support spatialite
> >>> >> would weigh it very heavily toward the spatialite side.   If the main
> goal is to
> >>> >> improve spatialite, perhaps a better approach is to build up the
> >>> >> current sqlite/spatialite plugin to do so?
> >>> >>
> >>> >> i am no user, so i'd ask jukka. what do you think is the better
> >>> >> starting point here?
> > Myself I will for sure use Spatialite extension with Larry's plugin but I
> consider that the plugin is pretty good as it is and I would not like to 
> pollute it
> much with extra decorations.
> 
> Jukka: did you ever use the mentioned sqlite/spatialite plugin? is there such
> a thing?

I suppose it is this one; I have been reading about it ;)
http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite#Using_SpatiaLite_with_Spatialite_Reader_Plugin

Michaël has touched the plugin code a bit lately and it is almost working 
again. It has some nice features like the possibility to test the query in a 
table view and function list and syntax help. On my computer it is suffering 
from the same "Unknown WKB type 0" problem with multigeometries. The plugin 
looks nice but is not as robust as DB Query plugin and it does not handle empty 
geometries and sometimes it is very slow.  It is a good model for another 
approach.

-Jukka-



--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Raster Color Editor 2

[Stefan Steiniger]

Hi Peppe,

sorry for this blurry answer:
But as far as I remember it uses a finite number of classes. At least I 
remember hacking in RGB values. Then the colouring is applied using 
equal-range classification (Each color-class has the same number of 
value). But it shoulnd't be too difficult to find out.
More fancy classification can be applied by converting the raster to 
vector (point or polygon) and using OJ-Vector styles.
Actually, for better data exploration I often chose this option, i.e. to 
convert to vector and then expect the range of values etc.

Excluding no-data values is possible by defining the range of values to 
color separately. You understand what I mean? I.e. figure out the range 
of raster values or the no data value using the profile tool, and then 
set that range, that does exclude the no-data value, in the color editor.

I did deactivate the no-data value at that time, as it would have taken 
too much time to figure out how that really worked. I.e. it did not work 
when I tested it. So the fastest way to have something ready was to 
simply deactivate it.

cheers,
stefan

Am 09.04.13 04:03, schrieb Giuseppe Aruta:
> Hi all,
> how Raster Color Editor defines how many intervals of color to apply to DTM?
> Is it set to a defined number? If it is a fix interval number, Is it
> possible to make user aware of this (example, instead to show "Raimbow",
> it would be better "Raimbow (12 intervals)"?
>
> regards
>
> peppe
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Raster Profile tool

[Stefan Steiniger]

Well, I am sure it is possible, but involves much more work.
The profile tool, just extracts the line and then I give the line and 
the raster to Sextantes profile function and it returns the values.

Your variant, like a "Pixel-Inspector", involves many more GUI stuff 
actions. Hence, needs more time to program.
However, you have seen that it is possible to have a line string that 
has multiple segments?

But as I said earlier, instead of a pixel-inspector, one may also chose 
to convert the raster to a vector and then use the info tool? perhaps?

cheers,
stefan

Am 09.04.13 03:59, schrieb Giuseppe Aruta:
> Hi all,
>
> raster profile tool is a very nice and useful tool. Thanks Stefan!
> I wonder if it is possible, by the time that a profile is created, that
> the tool remains active. So user can make multiple profiles (as a sort
> of INFO raster tool) instead of activate the tool every times on menu
>
> regards
>
> Peppe
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Select and delete raster image when opened by LoadRasterFile

[Stefan Steiniger]

sounds like a good FeatureRequest :)
but it should be selectable...?

Am 09.04.13 03:31, schrieb Giuseppe Aruta:
> Hi all,
> if I load a raster using OpenFilePlugIn (or OpenWizard not
> AddRasterImageLayerWizard), than raster is opened as a vector file.
> The curious situation is that user can  select raster on workbench (if
> edit option is enabled on context menu) and I can delete it.
> This behavior is not useful. User can use a raster file as a base map
> and, if they are not aware,   they can delete raster and need to reload
> it again when editing vector files.
> One solution could be to deactivate edit/modify on loading image raster
> regards
>
> Peppe
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Select and delete raster image when opened by LoadRasterFile

[edgar . soldin]

no it is not.. see Jukka's answer to it ;) .. ede

On 09.04.2013 17:11, Stefan Steiniger wrote:
> sounds like a good FeatureRequest :)
> but it should be selectable...?
> 
> Am 09.04.13 03:31, schrieb Giuseppe Aruta:
>> Hi all,
>> if I load a raster using OpenFilePlugIn (or OpenWizard not
>> AddRasterImageLayerWizard), than raster is opened as a vector file.
>> The curious situation is that user can  select raster on workbench (if
>> edit option is enabled on context menu) and I can delete it.
>> This behavior is not useful. User can use a raster file as a base map
>> and, if they are not aware,   they can delete raster and need to reload
>> it again when editing vector files.
>> One solution could be to deactivate edit/modify on loading image raster
>> regards
>>
>> Peppe
>>

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Enhancing DB Query Plugin with Spatialite functions.

[edgar . soldin]

On 09.04.2013 16:01, Rahkonen Jukka wrote:
> edgar soldin wrote:
>>
>> On 09.04.2013 15:33, Rahkonen Jukka wrote:
> Finally, the main purpose of the DBQuery plugin is to provide a
> bridge
>>> between OJ and spatial databases that it might not support (if
>>> any now), as well as provide a way to submit ad-hoc queries that
>>> don't have or need backing tables to return features.  While I'm
>>> glad my recent changes make it more useful for spatialite users,
>> adding all the native libs to support spatialite
>>> would weigh it very heavily toward the spatialite side.   If the main
>> goal is to
>>> improve spatialite, perhaps a better approach is to build up the
>>> current sqlite/spatialite plugin to do so?
>>>
>>> i am no user, so i'd ask jukka. what do you think is the better
>>> starting point here?
>>> Myself I will for sure use Spatialite extension with Larry's plugin but I
>> consider that the plugin is pretty good as it is and I would not like to 
>> pollute it
>> much with extra decorations.
>>
>> Jukka: did you ever use the mentioned sqlite/spatialite plugin? is there such
>> a thing?
> 
> I suppose it is this one; I have been reading about it ;)
> http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite#Using_SpatiaLite_with_Spatialite_Reader_Plugin
> 
> Michaël has touched the plugin code a bit lately and it is almost working 
> again. It has some nice features like the possibility to test the query in a 
> table view and function list and syntax help. On my computer it is suffering 
> from the same "Unknown WKB type 0" problem with multigeometries. The plugin 
> looks nice but is not as robust as DB Query plugin and it does not handle 
> empty geometries and sometimes it is very slow.  It is a good model for 
> another approach.
> 

question to all then

so what'd you suggest. rather

1. make sqlite plugin autoload spatiallite.dll and/or gdal (if possible) btw. 
who wrote this plugin?
2. allow the same for dbquery (it'd actually autoload if available and visually 
hint the non-/support)
3. don't do nothing, other topics more important :)

..ede

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [ jump-pilot-Bugs-3610388 ] NPE when undoing Add New Category

[SourceForge . net]

Bugs item #3610388, was opened at 2013-04-09 08:35
Message generated for change (Tracker Item Submitted) made by lreeder
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610388&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: OpenJUMP - Menu - Edit
Group: Linux / Unix
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Larry Reeder (lreeder)
Assigned to: Nobody/Anonymous (nobody)
Summary: NPE when undoing Add New Category

Initial Comment:
This is in build OpenJUMP-20130407-r3482-PLUS.

In OJ, do File-->New-->Category.   Rename the category.   Try to Undo by 
pressing ctrl+z or Edit-Undo.   You get the following stack trace:

java.lang.NullPointerException
at 
com.vividsolutions.jump.workbench.ui.plugin.AddNewCategoryPlugIn$1.unexecute(AddNewCategoryPlugIn.java:68)
at 
com.vividsolutions.jump.workbench.model.UndoableCommand$1.undo(UndoableCommand.java:122)
at javax.swing.undo.UndoManager.undoTo(UndoManager.java:320)
at javax.swing.undo.UndoManager.undo(UndoManager.java:398)
at 
com.vividsolutions.jump.workbench.ui.plugin.UndoPlugIn.execute(UndoPlugIn.java:77)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:284)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:809)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:850)
at java.awt.Component.processMouseEvent(Component.java:6288)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6053)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4651)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4481)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4481)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:643)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at 
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$2.run(EventQueue.java:616)
at java.awt.EventQueue$2.run(EventQueue.java:614)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:613)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

If you don't rename the Category (just do File-->New-->Category) and undo right 
away, OJ removes the category from the project tree.  Only tested on Linux, but 
may be a problem on other platforms.  

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610388&group_id=118054

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. D

Re: [JPP-Devel] Raster Color Editor 2

[Giuseppe Aruta]

Hi Stefan,
thanks for the answer. As I tested Raster Color Editor automatically
recognizes the range of values and excludes on color theming nodata one.
NODATA values always set to black color. I tested also to exclude some
values (for instance if I have a range between 504  and 863 , I set a range
between 600 to 863, excluding values below 600) and I had the same effects:
black color on excluded values.
I use Ubuntu and OpenJDK, it could be also a problem of these OS. I will
test on next days on my wife's laptop (Windows/Oracle JRE) ad see if there
is a difference.

thanks

Peppe



2013/4/9 Stefan Steiniger 

> Hi Peppe,
>
> sorry for this blurry answer:
> But as far as I remember it uses a finite number of classes. At least I
> remember hacking in RGB values. Then the colouring is applied using
> equal-range classification (Each color-class has the same number of
> value). But it shoulnd't be too difficult to find out.
> More fancy classification can be applied by converting the raster to
> vector (point or polygon) and using OJ-Vector styles.
> Actually, for better data exploration I often chose this option, i.e. to
> convert to vector and then expect the range of values etc.
>
> Excluding no-data values is possible by defining the range of values to
> color separately. You understand what I mean? I.e. figure out the range
> of raster values or the no data value using the profile tool, and then
> set that range, that does exclude the no-data value, in the color editor.
>
> I did deactivate the no-data value at that time, as it would have taken
> too much time to figure out how that really worked. I.e. it did not work
> when I tested it. So the fastest way to have something ready was to
> simply deactivate it.
>
> cheers,
> stefan
>
> Am 09.04.13 04:03, schrieb Giuseppe Aruta:
> > Hi all,
> > how Raster Color Editor defines how many intervals of color to apply to
> DTM?
> > Is it set to a defined number? If it is a fix interval number, Is it
> > possible to make user aware of this (example, instead to show "Raimbow",
> > it would be better "Raimbow (12 intervals)"?
> >
> > regards
> >
> > peppe
> >
> >
> >
> --
> > Precog is a next-generation analytics platform capable of advanced
> > analytics on semi-structured data. The platform includes APIs for
> building
> > apps and a phenomenal toolset for data science. Developers can use
> > our toolset for easy data analysis & visualization. Get a free account!
> > http://www2.precog.com/precogplatform/slashdotnewsletter
> >
> >
> >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Raster Profile tool

[Giuseppe Aruta]

Hi Stefan,
you are right: converting to vector is an option.
In my (few) test this procedure requires some time (sometimes a lot of
time) which is not convenient for a simple pixel-inspector (you are right.
This is my idea).
regards and thanks

Peppe

PS AFAIR there was a sort of pixel inspector tool on OJ the Merge, again
connected to GDAL drivers.


2013/4/9 Stefan Steiniger 

> Well, I am sure it is possible, but involves much more work.
> The profile tool, just extracts the line and then I give the line and
> the raster to Sextantes profile function and it returns the values.
>
> Your variant, like a "Pixel-Inspector", involves many more GUI stuff
> actions. Hence, needs more time to program.
> However, you have seen that it is possible to have a line string that
> has multiple segments?
>
> But as I said earlier, instead of a pixel-inspector, one may also chose
> to convert the raster to a vector and then use the info tool? perhaps?
>
> cheers,
> stefan
>
> Am 09.04.13 03:59, schrieb Giuseppe Aruta:
> > Hi all,
> >
> > raster profile tool is a very nice and useful tool. Thanks Stefan!
> > I wonder if it is possible, by the time that a profile is created, that
> > the tool remains active. So user can make multiple profiles (as a sort
> > of INFO raster tool) instead of activate the tool every times on menu
> >
> > regards
> >
> > Peppe
> >
> >
> >
> --
> > Precog is a next-generation analytics platform capable of advanced
> > analytics on semi-structured data. The platform includes APIs for
> building
> > apps and a phenomenal toolset for data science. Developers can use
> > our toolset for easy data analysis & visualization. Get a free account!
> > http://www2.precog.com/precogplatform/slashdotnewsletter
> >
> >
> >
> > ___
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [ jump-pilot-Bugs-3610388 ] NPE when undoing Add New Category

[SourceForge . net]

Bugs item #3610388, was opened at 2013-04-09 08:35
Message generated for change (Comment added) made by edso
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610388&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: OpenJUMP - Menu - Edit
Group: Linux / Unix
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Larry Reeder (lreeder)
Assigned to: Nobody/Anonymous (nobody)
Summary: NPE when undoing Add New Category

Initial Comment:
This is in build OpenJUMP-20130407-r3482-PLUS.

In OJ, do File-->New-->Category.   Rename the category.   Try to Undo by 
pressing ctrl+z or Edit-Undo.   You get the following stack trace:

java.lang.NullPointerException
at 
com.vividsolutions.jump.workbench.ui.plugin.AddNewCategoryPlugIn$1.unexecute(AddNewCategoryPlugIn.java:68)
at 
com.vividsolutions.jump.workbench.model.UndoableCommand$1.undo(UndoableCommand.java:122)
at javax.swing.undo.UndoManager.undoTo(UndoManager.java:320)
at javax.swing.undo.UndoManager.undo(UndoManager.java:398)
at 
com.vividsolutions.jump.workbench.ui.plugin.UndoPlugIn.execute(UndoPlugIn.java:77)
at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:284)
at 
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at 
javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2318)
at 
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387)
at 
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242)
at javax.swing.AbstractButton.doClick(AbstractButton.java:357)
at 
javax.swing.plaf.basic.BasicMenuItemUI.doClick(BasicMenuItemUI.java:809)
at 
javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(BasicMenuItemUI.java:850)
at java.awt.Component.processMouseEvent(Component.java:6288)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3267)
at java.awt.Component.processEvent(Component.java:6053)
at java.awt.Container.processEvent(Container.java:2041)
at java.awt.Component.dispatchEventImpl(Component.java:4651)
at java.awt.Container.dispatchEventImpl(Container.java:2099)
at java.awt.Component.dispatchEvent(Component.java:4481)
at 
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4577)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4238)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4168)
at java.awt.Container.dispatchEventImpl(Container.java:2085)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4481)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:643)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at 
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98)
at java.awt.EventQueue$2.run(EventQueue.java:616)
at java.awt.EventQueue$2.run(EventQueue.java:614)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:613)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

If you don't rename the Category (just do File-->New-->Category) and undo right 
away, OJ removes the category from the project tree.  Only tested on Linux, but 
may be a problem on other platforms.  

--

>Comment By: ede (edso)
Date: 2013-04-09 09:04

Message:
fixed in 3483 .. thanks! ede

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610388&group_id=118054

--
Precog is a next-generation analytics p

[JPP-Devel] [ jump-pilot-Bugs-3610401 ] Detachable AttributeTable throws Exception

[SourceForge . net]

Bugs item #3610401, was opened at 2013-04-09 11:23
Message generated for change (Tracker Item Submitted) made by michaudm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General / Other
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: michael michaud (michaudm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Detachable AttributeTable throws Exception

Initial Comment:
Detachable AttributeTable throws Exception if you want to make  the layer 
editable
The stacktrace is :

java.lang.ClassCastException: 
com.vividsolutions.jump.workbench.ui.TreeLayerNamePanel cannot be cast to 
com.vividsolutions.jump.workbench.ui.AttributeTab
 at 
com.vividsolutions.jump.workbench.ui.AttributeTab$16.execute(AttributeTab.java:565)
 at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:284)
 at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] The new geometry is invalid. Cancelled.

[Michaël Michaud]

Hi,
> Is it in OJ possible to check first for valid
> geometries when
> "Combine Selected Features"
> or is this a great problem?
>
> If it is a great problem maybe it is better
> "Combine Selected Features"
> makes always a geometrycollection?
There are several points :

1 - in the step by step process you described, error should
have been thrown while combining the two polygons, not
while moving the resulted invalid multipolygon

2 - I agree that in this case, building a valid GeometryCollection
is better than building an invalid Multipolygon, even if
GeometryCollection are much less useful (many operations
accepting MultiPolygon will fail on GeometryCollection).
If if no one has any objection, I propose to do the change.

3 - you surely knows that OpenJUMP has a hidden option to
accept/refuse invalid geometries during edit operations (in
this case, it is of no help though)

Regards,

Michaël
>
> What do you think?
>
> Regards
>
> Uwe
>
> Am 09.04.2013 03:21, schrieb Martin Davis:
>> As Michael and Stefan point out, Polygons in a MultiPolygon must be
>> edge-disjoint (which another way of stating the formal definition "must
>> only touch at a finite number of points".  If they touched along an
>> edge, that would cause an infinite number of points to be coincident).
>>
>> Another way of looking at this is that MultiPolygons are in a sense the
>> canonical description of a given area of the plane.  If edge touches or
>> overlaps were allowed then there would be an infinite number of
>> geometries which described the same area.
>>
>> Also, from the point of view of computing polygon overlay and spatial
>> relationships this is a nice rule to have, since it reduces the number
>> of cases which need to be checked for.  This makes the code simpler and
>> more performant.  The cost is that it is necessary to ensure that
>> MultiPolygons are valid at creation time.  This is a reasonable
>> tradeoff, since in general geometries are queried more often than they
>> are created.
>>
>> GeometryCollections on the other hand have no particular semantics -
>> they are just "bags" of geometries.  This makes them useful for holding
>> arbitrary sets of geometries, but makes them more complex (and sometimes
>> slower) to process.
>>
>> On 4/8/2013 11:04 AM, Michaël Michaud wrote:
>>> Hi Uwe, Stefan,
>>>
>>> OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform
>>>
>>> Here is the citation :
>>> Multipolygon
>>> 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon
>>> may not ‘cross’ and may touch
>>> at only a finite number of points. (Note that crossing is prevented by
>>> assertion 1 above).
>>>
>>> Don't ask me why, I've always thought it is strange that lines can
>>> share their boundaries in a MultiLineString and polygons cannot
>>> share an edge in a MultiPolygon, but it's a well established rule
>>> that JTS follows.
>>>
>>> Michaël
>>>
>>>
 Hi Uwe,

 I am not sure I would call it a bug. OJ, should (try to) create data
 that are OGC conform, but in this case it doesn't. Which means, the 
 case
 needs special treatment, but this is not implemented.

 That the multi-polygon causes an error is with the OGS SF 
 specification
 = correct. However, that the geometry collection does not cause an 
 error
 should be correct aw well, because there is, I believe, nothing said
 about geometry collections and their validity. Geometry collections
 should be allowed to have any type of geometries in what ever way they
 are drawn - like a "container". If we would check geometry collections
 for their validity it may be that people cannot store anymore the data
 they have. Hence, checking should be optional.

 But I guess here, Michael M. knows probably more about OGC 
 conformance?
 I'll also cc to JTS list.

 cheers,
 stefan

 PS: the Multi-polygon:

 MULTIPOLYGON (((
 80 125,
 80 241,
 175 241,
 175 125,
 80 125
 )), ((
 175 125,
 175 241,
 263 241,
 263 125,
 175 125
 )))

 Am 08.04.13 09:48, schrieb Uwe Dalluege:
> Hi Stefan,
>
> I am afraid I do not understand :-(
> Do you think this is a bug in OJ?
> The multipolygon causes an error
> the geometrycollection not.
>
> Is this behaviour OGC-conform (simpel features...)?
> What do you think?
>
> uwe
>
> Am 08.04.2013 16:36, schrieb Stefan Steiniger:
>> Hi,
>>
>> so - well the situation is not so nice, as it should be valid. 
>> However,
>> the JTS TestBuilder says the Multi-Polgyon is invalid because of
>> "Self-intersection at or near point (175.0, 125.0, NaN)"
>>
>> Same message appears when you try to add it as a new feat

Re: [JPP-Devel] Enhancing DB Query Plugin with Spatialite functions.

[Michaël Michaud]

Hi,
> On 09.04.2013 16:01, Rahkonen Jukka wrote:
>> edgar soldin wrote:
>>> On 09.04.2013 15:33, Rahkonen Jukka wrote:
>> Finally, the main purpose of the DBQuery plugin is to provide a
>> bridge
 between OJ and spatial databases that it might not support (if
 any now), as well as provide a way to submit ad-hoc queries that
 don't have or need backing tables to return features.  While I'm
 glad my recent changes make it more useful for spatialite users,
>>> adding all the native libs to support spatialite
 would weigh it very heavily toward the spatialite side.   If the main
>>> goal is to
 improve spatialite, perhaps a better approach is to build up the
 current sqlite/spatialite plugin to do so?

 i am no user, so i'd ask jukka. what do you think is the better
 starting point here?
 Myself I will for sure use Spatialite extension with Larry's plugin but I
>>> consider that the plugin is pretty good as it is and I would not like to 
>>> pollute it
>>> much with extra decorations.
>>>
>>> Jukka: did you ever use the mentioned sqlite/spatialite plugin? is there 
>>> such
>>> a thing?
>> I suppose it is this one; I have been reading about it ;)
>> http://sourceforge.net/apps/mediawiki/jump-pilot/index.php?title=OpenJUMP_with_SpatialLite#Using_SpatiaLite_with_Spatialite_Reader_Plugin
>>
>> Michaël has touched the plugin code a bit lately and it is almost working 
>> again. It has some nice features like the possibility to test the query in a 
>> table view and function list and syntax help. On my computer it is suffering 
>> from the same "Unknown WKB type 0" problem with multigeometries. The plugin 
>> looks nice but is not as robust as DB Query plugin and it does not handle 
>> empty geometries and sometimes it is very slow.  It is a good model for 
>> another approach.
>>
> question to all then
>
> so what'd you suggest. rather
>
> 1. make sqlite plugin autoload spatiallite.dll and/or gdal (if possible) btw. 
> who wrote this plugin?
> 2. allow the same for dbquery (it'd actually autoload if available and 
> visually hint the non-/support)
> 3. don't do nothing, other topics more important :)
I'm not a expert as Jukka in this area, but it seems that with its last 
addition
(loading of spatialite spatial function), dbquery now includes dbquery 
capabilities
and extend it (with other db access).
Moreover, it has an active maintener (Larry Reeder), which is a big +.
-> I would vote for working on DB Query PlugIn rather than dbquery

About 1.6 releasing, I would vote for DB Query PlugIn addition without 
dll in 1.6
(as asked by Jukka), and to take more time for integration of spatial 
function (which is
probably more complex). If a clean integration of DB Query PlugIn + dll 
is possible
soon, we'll make it available as an external plugin, or in the next PLUS 
release.

My 2 cents,

Michaël

>
> ..ede
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [ jump-pilot-Bugs-3610405 ] Combine should always produce valid geometries

[SourceForge . net]

Bugs item #3610405, was opened at 2013-04-09 12:03
Message generated for change (Tracker Item Submitted) made by michaudm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610405&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: JTS (Java Topology Suite)
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: michael michaud (michaudm)
Assigned to: michael michaud (michaudm)
Summary: Combine should always produce valid geometries

Initial Comment:
If one combine 2 contiguous polygons, OpenJUMP produces an invalid MultiPolygon.
Would be better to produce a GeometryCollection

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610405&group_id=118054

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

[JPP-Devel] [ jump-pilot-Bugs-3610405 ] Combine should always produce valid geometries

[SourceForge . net]

Bugs item #3610405, was opened at 2013-04-09 12:03
Message generated for change (Comment added) made by jratike80
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610405&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: JTS (Java Topology Suite)
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: michael michaud (michaudm)
Assigned to: michael michaud (michaudm)
Summary: Combine should always produce valid geometries

Initial Comment:
If one combine 2 contiguous polygons, OpenJUMP produces an invalid MultiPolygon.
Would be better to produce a GeometryCollection

--

>Comment By: Jukka Rahkonen (jratike80)
Date: 2013-04-09 12:35

Message:
Invalid multipolygon is bad but I am not totally sure if geometry
collection is always much better.  If user edits some real world data, like
cadastrial parcels, it is probably not possible to save the geometry
collection back to the original dataset. Perhaps the right solution would
have been to suggest user to merge polygons instead.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610405&group_id=118054

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] The new geometry is invalid. Cancelled.

[Stefan Steiniger]

> 2 - I agree that in this case, building a valid GeometryCollection
> is better than building an invalid Multipolygon, even if
> GeometryCollection are much less useful (many operations
> accepting MultiPolygon will fail on GeometryCollection).
> If if no one has any objection, I propose to do the change.

+1

but I see, you added already a feature request Michael.

stefan

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] The new geometry is invalid. Cancelled.

[Larry Becker]

Hi Michaël,

Echoing what I think you are proposing:

1) when Combine Selected Features is invoked, a basic topology validity
check is done on the result.

2) Any errors should be reported in the status bar or the Output Window.

3) If an invalid geometry results from building a MultiPolygon,  a
GeometryCollection is built instead.

+1 if this is the plan.  -1 if the plan is to just build a
GeometryCollection instead.

regards,

Larry

On Tue, Apr 9, 2013 at 1:36 PM, Michaël Michaud wrote:

> Hi,
> > Is it in OJ possible to check first for valid
> > geometries when
> > "Combine Selected Features"
> > or is this a great problem?
> >
> > If it is a great problem maybe it is better
> > "Combine Selected Features"
> > makes always a geometrycollection?
> There are several points :
>
> 1 - in the step by step process you described, error should
> have been thrown while combining the two polygons, not
> while moving the resulted invalid multipolygon
>
> 2 - I agree that in this case, building a valid GeometryCollection
> is better than building an invalid Multipolygon, even if
> GeometryCollection are much less useful (many operations
> accepting MultiPolygon will fail on GeometryCollection).
> If if no one has any objection, I propose to do the change.
>
> 3 - you surely knows that OpenJUMP has a hidden option to
> accept/refuse invalid geometries during edit operations (in
> this case, it is of no help though)
>
> Regards,
>
> Michaël
> >
> > What do you think?
> >
> > Regards
> >
> > Uwe
> >
> > Am 09.04.2013 03:21, schrieb Martin Davis:
> >> As Michael and Stefan point out, Polygons in a MultiPolygon must be
> >> edge-disjoint (which another way of stating the formal definition "must
> >> only touch at a finite number of points".  If they touched along an
> >> edge, that would cause an infinite number of points to be coincident).
> >>
> >> Another way of looking at this is that MultiPolygons are in a sense the
> >> canonical description of a given area of the plane.  If edge touches or
> >> overlaps were allowed then there would be an infinite number of
> >> geometries which described the same area.
> >>
> >> Also, from the point of view of computing polygon overlay and spatial
> >> relationships this is a nice rule to have, since it reduces the number
> >> of cases which need to be checked for.  This makes the code simpler and
> >> more performant.  The cost is that it is necessary to ensure that
> >> MultiPolygons are valid at creation time.  This is a reasonable
> >> tradeoff, since in general geometries are queried more often than they
> >> are created.
> >>
> >> GeometryCollections on the other hand have no particular semantics -
> >> they are just "bags" of geometries.  This makes them useful for holding
> >> arbitrary sets of geometries, but makes them more complex (and sometimes
> >> slower) to process.
> >>
> >> On 4/8/2013 11:04 AM, Michaël Michaud wrote:
> >>> Hi Uwe, Stefan,
> >>>
> >>> OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform
> >>>
> >>> Here is the citation :
> >>> Multipolygon
> >>> 2. The Boundaries of any 2 Polygons that are elements of a MultiPolygon
> >>> may not ‘cross’ and may touch
> >>> at only a finite number of points. (Note that crossing is prevented by
> >>> assertion 1 above).
> >>>
> >>> Don't ask me why, I've always thought it is strange that lines can
> >>> share their boundaries in a MultiLineString and polygons cannot
> >>> share an edge in a MultiPolygon, but it's a well established rule
> >>> that JTS follows.
> >>>
> >>> Michaël
> >>>
> >>>
>  Hi Uwe,
> 
>  I am not sure I would call it a bug. OJ, should (try to) create data
>  that are OGC conform, but in this case it doesn't. Which means, the
>  case
>  needs special treatment, but this is not implemented.
> 
>  That the multi-polygon causes an error is with the OGS SF
>  specification
>  = correct. However, that the geometry collection does not cause an
>  error
>  should be correct aw well, because there is, I believe, nothing said
>  about geometry collections and their validity. Geometry collections
>  should be allowed to have any type of geometries in what ever way they
>  are drawn - like a "container". If we would check geometry collections
>  for their validity it may be that people cannot store anymore the data
>  they have. Hence, checking should be optional.
> 
>  But I guess here, Michael M. knows probably more about OGC
>  conformance?
>  I'll also cc to JTS list.
> 
>  cheers,
>  stefan
> 
>  PS: the Multi-polygon:
> 
>  MULTIPOLYGON (((
>  80 125,
>  80 241,
>  175 241,
>  175 125,
>  80 125
>  )), ((
>  175 125,
>  175 241,
>  263 241,
>  263 125,
>  175 125
> >

[JPP-Devel] [ jump-pilot-Bugs-3610401 ] Detachable AttributeTable throws Exception

[SourceForge . net]

Bugs item #3610401, was opened at 2013-04-09 11:23
Message generated for change (Comment added) made by edso
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General / Other
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: michael michaud (michaudm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Detachable AttributeTable throws Exception

Initial Comment:
Detachable AttributeTable throws Exception if you want to make  the layer 
editable
The stacktrace is :

java.lang.ClassCastException: 
com.vividsolutions.jump.workbench.ui.TreeLayerNamePanel cannot be cast to 
com.vividsolutions.jump.workbench.ui.AttributeTab
 at 
com.vividsolutions.jump.workbench.ui.AttributeTab$16.execute(AttributeTab.java:565)
 at 
com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:284)
 at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
...

--

>Comment By: ede (edso)
Date: 2013-04-09 14:28

Message:
fixed in 3484 .. ede

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [ jump-pilot-Bugs-3610401 ] Detachable AttributeTable throws Exception

[Michaël Michaud]

Thanks for the fix for #3610401 ,

Seems you forgot to commit something in your last change,

java.lang.IncompatibleClassChangeError: Expecting non-static method 
com.vividsol
utions.jump.workbench.ui.plugin.ViewAttributesPlugIn.getIcon()Ljavax/swing/Image
Icon;
 at 
com.vividsolutions.jump.workbench.JUMPConfiguration.configureToolBar(
JUMPConfiguration.java:1307)
 at 
com.vividsolutions.jump.workbench.JUMPConfiguration.setup(JUMPConfigu
ration.java:380)
 at 
com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.ja
va:429)
 at 
com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.ja
va:381)

> Bugs item #3610401, was opened at 2013-04-09 11:23
> Message generated for change (Comment added) made by edso
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054
>
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: General / Other
> Group: None
>> Status: Closed
>> Resolution: Fixed
> Priority: 5
> Private: No
> Submitted By: michael michaud (michaudm)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Detachable AttributeTable throws Exception
>
> Initial Comment:
> Detachable AttributeTable throws Exception if you want to make  the layer 
> editable
> The stacktrace is :
>
> java.lang.ClassCastException: 
> com.vividsolutions.jump.workbench.ui.TreeLayerNamePanel cannot be cast to 
> com.vividsolutions.jump.workbench.ui.AttributeTab
>   at 
> com.vividsolutions.jump.workbench.ui.AttributeTab$16.execute(AttributeTab.java:565)
>   at 
> com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:284)
>   at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
> ...
>
> --
>
>> Comment By: ede (edso)
> Date: 2013-04-09 14:28
>
> Message:
> fixed in 3484 .. ede
>
> --
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] Spatialite multigeometry trouble and JTS v. 1.13

[Larry Reeder]

Thanks for the sample DB, Jukka.  I will try to take a look this weekend.

 -lreeder


On Mon, Apr 8, 2013 at 2:01 AM, Rahkonen Jukka wrote:

> Hi,
>
> While testing the new 0.8.1 version of DB Query Plugin I noticed that I
> could not read any multigeometries nor geometry collections from
> Spatialite. Further research revealed that with a bit older OpenJUMP
> versions there are no troubles at all with these geometries.  For example
> OJ r3131 from 2012-12-12 works fine for me.
> The error with recent OJ versions is "Unknown WKB type 0".
>
> running query: select * from multipolygons
> Warning: Unable to find FDO-OGR metadata:  [SQLITE_ERROR] SQL error or
> missing database (no such col
> umn: geometry_format).  I'll take this as an indication that this database
> doesn't conform to FDO RF
> C 16, but is just a regular spatialite (or sqlite) database
> java.sql.SQLException: Unknown WKB type 0
> at
> org.freevoice.jumpdbqueryextension.spatialite.JumpSpatialiteDbQuery.getAttributeValueFrom
> Results(JumpSpatialiteDbQuery.java:455)
> at
> org.freevoice.jumpdbqueryextension.AbstractJumpDbQuery.addFeatureToCollection(AbstractJum
> pDbQuery.java:132)
> at
> org.freevoice.jumpdbqueryextension.spatialite.JumpSpatialiteDbQuery.getCollection(JumpSpa
> tialiteDbQuery.java:404)
> at
> org.freevoice.jumpdbqueryextension.JumpDbQueryPlugin.run(JumpDbQueryPlugin.java:169)
> at java.lang.Thread.run(Unknown Source)
>
> I made a little test Spatialite v.3 database which contains points,
> linestrings, multilinestrings, polygons, multipolygons and geometry
> collections with 10 features on each layer to test with
> http://latuviitta.org/documents/Geometry_type_test.sqlite
>
> If I could I would have a look at changeset 3137: update jts library to
> 1.13
>
> -Jukka Rahkonen
>
>
> --
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] [ jump-pilot-Bugs-3610401 ] Detachable AttributeTable throws Exception

[Michaël Michaud]

Hi,

Sorry for the noise, the problem has gone after a fresh build.

Michaël
> Thanks for the fix for #3610401 ,
>
> Seems you forgot to commit something in your last change,
>
> java.lang.IncompatibleClassChangeError: Expecting non-static method
> com.vividsol
> utions.jump.workbench.ui.plugin.ViewAttributesPlugIn.getIcon()Ljavax/swing/Image
> Icon;
>   at
> com.vividsolutions.jump.workbench.JUMPConfiguration.configureToolBar(
> JUMPConfiguration.java:1307)
>   at
> com.vividsolutions.jump.workbench.JUMPConfiguration.setup(JUMPConfigu
> ration.java:380)
>   at
> com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.ja
> va:429)
>   at
> com.vividsolutions.jump.workbench.JUMPWorkbench.main(JUMPWorkbench.ja
> va:381)
>
>> Bugs item #3610401, was opened at 2013-04-09 11:23
>> Message generated for change (Comment added) made by edso
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054
>>
>> Please note that this message will contain a full copy of the comment thread,
>> including the initial issue submission, for this request,
>> not just the latest update.
>> Category: General / Other
>> Group: None
>>> Status: Closed
>>> Resolution: Fixed
>> Priority: 5
>> Private: No
>> Submitted By: michael michaud (michaudm)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: Detachable AttributeTable throws Exception
>>
>> Initial Comment:
>> Detachable AttributeTable throws Exception if you want to make  the layer 
>> editable
>> The stacktrace is :
>>
>> java.lang.ClassCastException: 
>> com.vividsolutions.jump.workbench.ui.TreeLayerNamePanel cannot be cast to 
>> com.vividsolutions.jump.workbench.ui.AttributeTab
>>at 
>> com.vividsolutions.jump.workbench.ui.AttributeTab$16.execute(AttributeTab.java:565)
>>at 
>> com.vividsolutions.jump.workbench.plugin.AbstractPlugIn$1.actionPerformed(AbstractPlugIn.java:284)
>>at 
>> javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
>> ...
>>
>> --
>>
>>> Comment By: ede (edso)
>> Date: 2013-04-09 14:28
>>
>> Message:
>> fixed in 3484 .. ede
>>
>> --
>>
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=679906&aid=3610401&group_id=118054
>>
>> --
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>>
>
> --
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>


--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Re: [JPP-Devel] The new geometry is invalid. Cancelled.

[Michaël Michaud]

Hi Martin,

I just noticed that the code we use for the CombineSelectedFeature plugin
is very close to GeometryFactory.buildGeometry() method.
Hence, I checked buildGeomery code and found that in the particular case
of two adjacent polygons, it will also produce an invalid geometry.

I don't know what would be the cost of an extra test for validity, but I 
think
buildGeometry should never return invalid geometries from valid input.

Best regards,

Michaël

> Hi,
>> Is it in OJ possible to check first for valid
>> geometries when
>> "Combine Selected Features"
>> or is this a great problem?
>>
>> If it is a great problem maybe it is better
>> "Combine Selected Features"
>> makes always a geometrycollection?
> There are several points :
>
> 1 - in the step by step process you described, error should
> have been thrown while combining the two polygons, not
> while moving the resulted invalid multipolygon
>
> 2 - I agree that in this case, building a valid GeometryCollection
> is better than building an invalid Multipolygon, even if
> GeometryCollection are much less useful (many operations
> accepting MultiPolygon will fail on GeometryCollection).
> If if no one has any objection, I propose to do the change.
>
> 3 - you surely knows that OpenJUMP has a hidden option to
> accept/refuse invalid geometries during edit operations (in
> this case, it is of no help though)
>
> Regards,
>
> Michaël
>>
>> What do you think?
>>
>> Regards
>>
>> Uwe
>>
>> Am 09.04.2013 03:21, schrieb Martin Davis:
>>> As Michael and Stefan point out, Polygons in a MultiPolygon must be
>>> edge-disjoint (which another way of stating the formal definition "must
>>> only touch at a finite number of points".  If they touched along an
>>> edge, that would cause an infinite number of points to be coincident).
>>>
>>> Another way of looking at this is that MultiPolygons are in a sense the
>>> canonical description of a given area of the plane.  If edge touches or
>>> overlaps were allowed then there would be an infinite number of
>>> geometries which described the same area.
>>>
>>> Also, from the point of view of computing polygon overlay and spatial
>>> relationships this is a nice rule to have, since it reduces the number
>>> of cases which need to be checked for.  This makes the code simpler and
>>> more performant.  The cost is that it is necessary to ensure that
>>> MultiPolygons are valid at creation time.  This is a reasonable
>>> tradeoff, since in general geometries are queried more often than they
>>> are created.
>>>
>>> GeometryCollections on the other hand have no particular semantics -
>>> they are just "bags" of geometries.  This makes them useful for holding
>>> arbitrary sets of geometries, but makes them more complex (and 
>>> sometimes
>>> slower) to process.
>>>
>>> On 4/8/2013 11:04 AM, Michaël Michaud wrote:
 Hi Uwe, Stefan,

 OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform

 Here is the citation :
 Multipolygon
 2. The Boundaries of any 2 Polygons that are elements of a 
 MultiPolygon
 may not ‘cross’ and may touch
 at only a finite number of points. (Note that crossing is prevented by
 assertion 1 above).

 Don't ask me why, I've always thought it is strange that lines can
 share their boundaries in a MultiLineString and polygons cannot
 share an edge in a MultiPolygon, but it's a well established rule
 that JTS follows.

 Michaël


> Hi Uwe,
>
> I am not sure I would call it a bug. OJ, should (try to) create data
> that are OGC conform, but in this case it doesn't. Which means, 
> the case
> needs special treatment, but this is not implemented.
>
> That the multi-polygon causes an error is with the OGS SF 
> specification
> = correct. However, that the geometry collection does not cause an 
> error
> should be correct aw well, because there is, I believe, nothing said
> about geometry collections and their validity. Geometry collections
> should be allowed to have any type of geometries in what ever way 
> they
> are drawn - like a "container". If we would check geometry 
> collections
> for their validity it may be that people cannot store anymore the 
> data
> they have. Hence, checking should be optional.
>
> But I guess here, Michael M. knows probably more about OGC 
> conformance?
> I'll also cc to JTS list.
>
> cheers,
> stefan
>
> PS: the Multi-polygon:
>
> MULTIPOLYGON (((
> 80 125,
> 80 241,
> 175 241,
> 175 125,
> 80 125
> )), ((
> 175 125,
> 175 241,
> 263 241,
> 263 125,
> 175 125
> )))
>
> Am 08.04.13 09:48, schrieb Uwe Dalluege:
>> Hi Stefan,
>>

Re: [JPP-Devel] The new geometry is invalid. Cancelled.

[Michaël Michaud]

Hi Martin,
> I just noticed that the code we use for the CombineSelectedFeature plugin
> is very close to GeometryFactory.buildGeometry() method.
> Hence, I checked buildGeomery code and found that in the particular case
> of two adjacent polygons, it will also produce an invalid geometry.
And probably also in all the cases of overlapping polygons, which means the
suggested change is not just a corner case.

Michaël
>
> I don't know what would be the cost of an extra test for validity, but I
> think
> buildGeometry should never return invalid geometries from valid input.
>
> Best regards,
>
> Michaël
>
>> Hi,
>>> Is it in OJ possible to check first for valid
>>> geometries when
>>> "Combine Selected Features"
>>> or is this a great problem?
>>>
>>> If it is a great problem maybe it is better
>>> "Combine Selected Features"
>>> makes always a geometrycollection?
>> There are several points :
>>
>> 1 - in the step by step process you described, error should
>> have been thrown while combining the two polygons, not
>> while moving the resulted invalid multipolygon
>>
>> 2 - I agree that in this case, building a valid GeometryCollection
>> is better than building an invalid Multipolygon, even if
>> GeometryCollection are much less useful (many operations
>> accepting MultiPolygon will fail on GeometryCollection).
>> If if no one has any objection, I propose to do the change.
>>
>> 3 - you surely knows that OpenJUMP has a hidden option to
>> accept/refuse invalid geometries during edit operations (in
>> this case, it is of no help though)
>>
>> Regards,
>>
>> Michaël
>>> What do you think?
>>>
>>> Regards
>>>
>>> Uwe
>>>
>>> Am 09.04.2013 03:21, schrieb Martin Davis:
 As Michael and Stefan point out, Polygons in a MultiPolygon must be
 edge-disjoint (which another way of stating the formal definition "must
 only touch at a finite number of points".  If they touched along an
 edge, that would cause an infinite number of points to be coincident).

 Another way of looking at this is that MultiPolygons are in a sense the
 canonical description of a given area of the plane.  If edge touches or
 overlaps were allowed then there would be an infinite number of
 geometries which described the same area.

 Also, from the point of view of computing polygon overlay and spatial
 relationships this is a nice rule to have, since it reduces the number
 of cases which need to be checked for.  This makes the code simpler and
 more performant.  The cost is that it is necessary to ensure that
 MultiPolygons are valid at creation time.  This is a reasonable
 tradeoff, since in general geometries are queried more often than they
 are created.

 GeometryCollections on the other hand have no particular semantics -
 they are just "bags" of geometries.  This makes them useful for holding
 arbitrary sets of geometries, but makes them more complex (and
 sometimes
 slower) to process.

 On 4/8/2013 11:04 AM, Michaël Michaud wrote:
> Hi Uwe, Stefan,
>
> OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform
>
> Here is the citation :
> Multipolygon
> 2. The Boundaries of any 2 Polygons that are elements of a
> MultiPolygon
> may not ‘cross’ and may touch
> at only a finite number of points. (Note that crossing is prevented by
> assertion 1 above).
>
> Don't ask me why, I've always thought it is strange that lines can
> share their boundaries in a MultiLineString and polygons cannot
> share an edge in a MultiPolygon, but it's a well established rule
> that JTS follows.
>
> Michaël
>
>
>> Hi Uwe,
>>
>> I am not sure I would call it a bug. OJ, should (try to) create data
>> that are OGC conform, but in this case it doesn't. Which means,
>> the case
>> needs special treatment, but this is not implemented.
>>
>> That the multi-polygon causes an error is with the OGS SF
>> specification
>> = correct. However, that the geometry collection does not cause an
>> error
>> should be correct aw well, because there is, I believe, nothing said
>> about geometry collections and their validity. Geometry collections
>> should be allowed to have any type of geometries in what ever way
>> they
>> are drawn - like a "container". If we would check geometry
>> collections
>> for their validity it may be that people cannot store anymore the
>> data
>> they have. Hence, checking should be optional.
>>
>> But I guess here, Michael M. knows probably more about OGC
>> conformance?
>> I'll also cc to JTS list.
>>
>> cheers,
>> stefan
>>
>> PS: the Multi-polygon:
>>
>> MULTIPOLYGON (((
>>  80 125,
>>  80 241,
>>  175 241,
>>  175 125,
>>  80 125
>>  )

Re: [JPP-Devel] The new geometry is invalid. Cancelled.

[Michaël Michaud]

Hi Larry,

Thanks for the input,
I followed your suggestion to add a warning in the status bar.
I did the test for the MultiPolygon case only though.

Not sure it is useful in the general case. Maybe it would be
better to make the plugin consistent with the edit tools option
"accept invalid geometry". I think it is not yet.

Michaël


Hi Michaël,

Echoing what I think you are proposing:

1) when Combine Selected Features is invoked, a basic topology 
validity check is done on the result.


2) Any errors should be reported in the status bar or the Output Window.

3) If an invalid geometry results from building a MultiPolygon,  a 
GeometryCollection is built instead.


+1 if this is the plan.  -1 if the plan is to just build a 
GeometryCollection instead.


regards,

Larry

On Tue, Apr 9, 2013 at 1:36 PM, Michaël Michaud 
mailto:michael.mich...@free.fr>> wrote:


Hi,
> Is it in OJ possible to check first for valid
> geometries when
> "Combine Selected Features"
> or is this a great problem?
>
> If it is a great problem maybe it is better
> "Combine Selected Features"
> makes always a geometrycollection?
There are several points :

1 - in the step by step process you described, error should
have been thrown while combining the two polygons, not
while moving the resulted invalid multipolygon

2 - I agree that in this case, building a valid GeometryCollection
is better than building an invalid Multipolygon, even if
GeometryCollection are much less useful (many operations
accepting MultiPolygon will fail on GeometryCollection).
If if no one has any objection, I propose to do the change.

3 - you surely knows that OpenJUMP has a hidden option to
accept/refuse invalid geometries during edit operations (in
this case, it is of no help though)

Regards,

Michaël
>
> What do you think?
>
> Regards
>
> Uwe
>
> Am 09.04.2013 03:21, schrieb Martin Davis:
>> As Michael and Stefan point out, Polygons in a MultiPolygon must be
>> edge-disjoint (which another way of stating the formal
definition "must
>> only touch at a finite number of points".  If they touched along an
>> edge, that would cause an infinite number of points to be
coincident).
>>
>> Another way of looking at this is that MultiPolygons are in a
sense the
>> canonical description of a given area of the plane.  If edge
touches or
>> overlaps were allowed then there would be an infinite number of
>> geometries which described the same area.
>>
>> Also, from the point of view of computing polygon overlay and
spatial
>> relationships this is a nice rule to have, since it reduces the
number
>> of cases which need to be checked for.  This makes the code
simpler and
>> more performant.  The cost is that it is necessary to ensure that
>> MultiPolygons are valid at creation time.  This is a reasonable
>> tradeoff, since in general geometries are queried more often
than they
>> are created.
>>
>> GeometryCollections on the other hand have no particular
semantics -
>> they are just "bags" of geometries.  This makes them useful for
holding
>> arbitrary sets of geometries, but makes them more complex (and
sometimes
>> slower) to process.
>>
>> On 4/8/2013 11:04 AM, Michaël Michaud wrote:
>>> Hi Uwe, Stefan,
>>>
>>> OpenJUMP (JTS) is right, this MultiPolygon is not OGC conform
>>>
>>> Here is the citation :
>>> Multipolygon
>>> 2. The Boundaries of any 2 Polygons that are elements of a
MultiPolygon
>>> may not 'cross' and may touch
>>> at only a finite number of points. (Note that crossing is
prevented by
>>> assertion 1 above).
>>>
>>> Don't ask me why, I've always thought it is strange that lines can
>>> share their boundaries in a MultiLineString and polygons cannot
>>> share an edge in a MultiPolygon, but it's a well established rule
>>> that JTS follows.
>>>
>>> Michaël
>>>
>>>
 Hi Uwe,

 I am not sure I would call it a bug. OJ, should (try to)
create data
 that are OGC conform, but in this case it doesn't. Which
means, the
 case
 needs special treatment, but this is not implemented.

 That the multi-polygon causes an error is with the OGS SF
 specification
 = correct. However, that the geometry collection does not
cause an
 error
 should be correct aw well, because there is, I believe,
nothing said
 about geometry collections and their validity. Geometry
collections
 should be allowed to have any type of geometries in what ever
way they
 are drawn - like a "container". If we would check geometry
collections
 for their validity it may be that people cannot store anymore