Re: [JPP-Devel] JTS update: first experiments

2020-08-07 Thread Eric

Hi again,

After another try, I managed to properly import the JTS io GeoJSON part. 
Here is the dependency to use:


    org.locationtech.jts.io
    jts-io-common
    1.17.0


And not:

    org.locationtech.jts
    jts-io
    1.17.0
    pom


This solves all the remaining problems with JTS and JTS imports, 
excluding the ones which are link with some code modifications between 
the two versions (1.14 and 1.17). I'll manage these ones later manually.


I also managed to solve the deegree-core 3 imports. Rather than using a 
pom type, the easiest solution is to import each individual module, such as:


    org.deegree
    deegree-core-commons
    3.4.13


Now it's just a game to see where the different classes and concepts 
have been moved, such as org.deegree.cs.* replacing 
org.deegree.model.crs.* with different paths. For example, 
org.deegree.model.crs.UnknownCRSException replaced 
org.deegree.cs.exceptions.UnknownCRSException, 
org.deegree.commons.utils.StringUtils/ ArrayUtils replacing 
org.deegree.framework.util.StringTools, or 
org.deegree.commons.xml.CommonNamespaces replacing 
org.deegree.ogcbase.CommonNamespaces. Behind the scene, it's apparently 
the exact same code, which is a good news.


That's me for today. Hope it helps.

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


[JPP-Devel] JTS update: first experiments

2020-08-07 Thread Eric

Hi all,

Here are the different steps I made to try updating JTS to at least 
1.15, the last one being 1.17.



The first thing I did was to install OpenJUMP (core / trunk) via SVN in 
my IDE.


I realised that two Maven repositories are outdated in the 
configuration, Central Maven 2
(http://central.maven.org/maven2) and Cambridge Maven 2 
(https://maven.ch.cam.ac.uk/m2repo/).


The first one could be replaced by the kind of new Maven Central 
repository, used by JTS:


    Maven Central group
    Maven Central group Repository
    https://mvnrepository.com/artifact/


By adding this last one, it would mean that the OpenJUMP Maven 
repositories aren't totally

internally dependent, because otherwise they rely mostly on:
http://jump-pilot.sourceforge.net/repository/

Even if it is sufficient in a certain extent, I encountered some 
problems this morning when
I tried to import the Maven dependencies, having a joyful "Failed to 
transfer [...] Error code
429, Too Many Requests". I imagine that some other services are slightly 
more permissive.



Then I checked which OJ lib dependencies rely on JTS and it seems that 
there is only deegree 2,
without considering here the plethora of extensions/plugins. This is 
quite a good news because
if the deegree dependency is updated to its latest version (3.x.x), 
which relies on JTS 1.15,
then, theoretically, only the import statements and a few other 
com.vividsolutions directly used in the code

need to be modified.

It was therefore time to remove the current OJ JTS dependencies in the 
Maven configuration

and to replace them with:


    org.locationtech.jts
    jts-core
    1.17.0


    org.locationtech.jts
    jts-io
    1.17.0
    pom


Note that the second dependency has a pom type. Therefore, by default, 
it didn't import
the jts-io related code, based on the current Maven configuration. This 
JTS IO pom
only refers to some modules, including the one (common) containing the 
GeoJSON related code

(reader, writer, etc.) used in OpenJUMP. See:
- (code) https://github.com/locationtech/jts/tree/master/modules/io/common
- 
(pom)https://repo1.maven.org/maven2/org/locationtech/jts/jts-io/1.17.0/jts-io-1.17.0.pom


It was time to replace com.vividsolutions.jts. by org.locationtech.jts. 
Using Eclipse as an IDE,
it was a straightforward move. A quick CTRL + H did the trick in a 
matter of seconds.


In terms of results, it's pretty good:
- it worked globally well,

- the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic 
due to the jts-io
pom type only, but once imported, this part of the code will be 
functional again,


- some classes have been deprecated, removed, or simply moved in the new 
JTS versions,
such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. 
New interfaces
have been created in JTS. It shouldn't be too complex to find a solution 
or a workaround,



At that stage, most of the errors I had, were related to deegree. I 
tried to import

deegree-core 3 using (note the pom type again):

    org.deegree
    deegree-core
    3.4.13
    pom


and I added this Maven repository:

    deegree artifacts
    deegree artifacts Repository
http://repo.deegree.org/content/repositories/releases/


Same problem than with JTS io, it doesn't import anything as it is a 
parent pom linking
to some modules: 
https://github.com/deegree/deegree3/tree/master/deegree-core


At that point, I started experimenting a bit with:

  
    
  
  
  
    
 


rather than the classic:

    
  
  
    
 

without much success. I also tried to use the import scope 
(import)
with the pom type, but as they can only be managed inside 
,
which is basically used in parent poms, it didn't help much, except if 
the project is reconfigured.


I'm now reading some documentations about Maven and the recent changes 
to see how
I can tackle this "pom type" problem without the need to import all of 
the submodules

manually.

Another aspect of the deegree 3 dependency is that deegree-core relies 
on a certain

number of common OJ dependencies. Here are the ones I identified:
- log4j / log4j (same version in both projects: 1.2.17) -- it would be 
good to upgrade
to log4j 2 because there is a security problem in v1 and it isn't 
maintained anymore

(see http://logging.apache.org/log4j/1.2/)
- org.slf4j / slf4j-api (deegree 1.7.13 vs OJ 1.7.25),
- org.slf4j / slf4j-log4j12 (deegree 1.7.13 vs OJ 1.7.25),
- org.locationtech.jts / jts-core (deegree 1.7.13 vs OJ 1.17 potentially 
but 1.15 woud probably

be OK for the time being),
- xerces / xercesImpl (deegree 2.12.0 vs OJ 2.11.0),
- org.postgresql / postgresql (deegree 42.2.8 vs OJ 9.4.1208.jre6),
- org.apache.xmlgraphics / batik-awt-util (deegree 1.7 vs OJ 1.13), just 
updated on the OJ

side a couple of days ago,
- same with org.apache.xmlgraphics / batik-dom,
- junit / junit (same version in both projects: 1.12),
- commons-codec / commons-codec (deegree 1.7 vs OJ 1.14),
- commons-io / commons-io 

Re: [JPP-Devel] OpenJUMP new contributor

2020-08-07 Thread Giuseppe Aruta
Welcome Eric. It is really nice to see you back on the list and to
have your contribution to the project.
Peppe

2020-08-07 19:39 GMT+02:00, Eric :
> Hi everyone,
>
> Note: I just changed the email address I'd like to use to contribute on
> this list.
>
>
> Thank you Michael for your welcome on this list and your kind message.
>
> As Michaël pointed out, I started updating some former OpenJUMP
> extensions that I created years ago, and I've recently been in touch
> with him to know a bit more about the evolution of OpenJUMP. We talked
> about the dependencies, including JTS and deegree, the best way to
> import the project, a possible move to Git (Gitlab, Github, etc.), etc.
>
> So yes, I know OpenJUMP in a certain extent but I'm far from being an
> expert despite the fact that I developed these extensions. To be totally
> honest, I didn't code much in Java during the last 3 or 4 years, so I'm
> probably a bit rusty. For these reasons, I am quite happy to talk about
> what I experimented with during the recent days, including a possible
> update to a "new" version of JTS (com.vividsolutions renamed into
> org.locationtech), etc., but I don't feel confident, at least for now,
> to modify the Maven configuration and to commit these changes. Michaël
> said that Ede was really good at it, and I would prefer relying on his
> skills rather than my mine at the moment to push the commit
> button/command line. That said, I'm quite happy to discuss what could
> possibly be updated, and to update/commit some of the code, for example
> to improve all the generic types such as HashMap.
>
> Rather than writing more about it in this introductory message, I'll
> write another message tonight about what I just did today.
>
> Best wishes to all of you.
> Take care,
> Eric
>
> On 07/08/2020 16:21, Michaud Michaël wrote:
>>
>> Hi all,
>>
>> I reconnected with Eric Grosso, a former colleague who is also an
>> OpenJUMP expert as he wrote the MorphAl extension
>> (https://alpage.huma-num.fr/extension-sig/), the concave hull
>> extension (now incorporated in OJ-PLUS) and probably some other useful
>> contributions.
>>
>> He already noticed several outdated repositories in the pom an we
>> talked a little bit about the future of OpenJUMP (including some
>> recurrent questions like migration to github,
>> org.locationtech.jts...). I invited him to continue the discussion on
>> this list and want to welcome him.
>>
>> Michaël
>>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>


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


Re: [JPP-Devel] OpenJUMP new contributor

2020-08-07 Thread Eric

Hi everyone,

Note: I just changed the email address I'd like to use to contribute on 
this list.



Thank you Michael for your welcome on this list and your kind message.

As Michaël pointed out, I started updating some former OpenJUMP 
extensions that I created years ago, and I've recently been in touch 
with him to know a bit more about the evolution of OpenJUMP. We talked 
about the dependencies, including JTS and deegree, the best way to 
import the project, a possible move to Git (Gitlab, Github, etc.), etc.


So yes, I know OpenJUMP in a certain extent but I'm far from being an 
expert despite the fact that I developed these extensions. To be totally 
honest, I didn't code much in Java during the last 3 or 4 years, so I'm 
probably a bit rusty. For these reasons, I am quite happy to talk about 
what I experimented with during the recent days, including a possible 
update to a "new" version of JTS (com.vividsolutions renamed into 
org.locationtech), etc., but I don't feel confident, at least for now, 
to modify the Maven configuration and to commit these changes. Michaël 
said that Ede was really good at it, and I would prefer relying on his 
skills rather than my mine at the moment to push the commit 
button/command line. That said, I'm quite happy to discuss what could 
possibly be updated, and to update/commit some of the code, for example 
to improve all the generic types such as HashMap.


Rather than writing more about it in this introductory message, I'll 
write another message tonight about what I just did today.


Best wishes to all of you.
Take care,
Eric

On 07/08/2020 16:21, Michaud Michaël wrote:


Hi all,

I reconnected with Eric Grosso, a former colleague who is also an 
OpenJUMP expert as he wrote the MorphAl extension 
(https://alpage.huma-num.fr/extension-sig/), the concave hull 
extension (now incorporated in OJ-PLUS) and probably some other useful 
contributions.


He already noticed several outdated repositories in the pom an we 
talked a little bit about the future of OpenJUMP (including some 
recurrent questions like migration to github, 
org.locationtech.jts...). I invited him to continue the discussion on 
this list and want to welcome him.


Michaël




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


[JPP-Devel] OpenJUMP new contributor

2020-08-07 Thread Michaud Michael


Hi all,I reconnected with Eric Grosso, a former colleague who is also an OpenJUMP expert as he wrote the MorphAl extension (https://alpage.huma-num.fr/extension-sig/), the concave hull extension (now incorporated in OJ-PLUS) and probably some other useful contributions.He already noticed several outdated repositories in the pom an we talked a little bit about the future of OpenJUMP (including some recurrent questions like migration to github, org.locationtech.jts...). I invited him to continue the discussion on this list and want to welcome him.Michaël 

___
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] #494 Load WKT file with set options

2020-08-07 Thread Jukka Rahkonen via Jump-pilot-devel
It may feel strange but after all WKT handles just geometries as defined in the 
standard https://portal.ogc.org/files/?artifact_id=25355. Perhaps the issue is 
calling file with WKT and attributes as "WKT file" instead of calling it as 
"CSV file with WKT".

Saving geometries into WKT is possible without any options because everything 
is defined in the standard. There is no standard about CSV and therefore 
options for selecting the separator etc. are needed.

But of course we want that it is easy to understand the meaning of different 
file format options and appreciate all suggestions for improvements.

As a comparison in GDAL the single CSV driver offers the capabilities with and 
without WKT https://gdal.org/drivers/vector/csv.html.


---

** [bugs:#494] Load WKT file with set options**

**Status:** pending
**Labels:** WKT WKT (set options) 
**Created:** Thu Jul 30, 2020 08:54 AM UTC by János Tamás Kis
**Last Updated:** Thu Aug 06, 2020 08:53 AM UTC
**Owner:** michael michaud
**Attachments:**

- 
[proba.jmp](https://sourceforge.net/p/jump-pilot/bugs/494/attachment/proba.jmp) 
(6.5 kB; application/octet-stream)
- 
[proba.wkt](https://sourceforge.net/p/jump-pilot/bugs/494/attachment/proba.wkt) 
(149 Bytes; application/octet-stream)
- 
[reverse.jmp](https://sourceforge.net/p/jump-pilot/bugs/494/attachment/reverse.jmp)
 (7.2 kB; application/octet-stream)
- 
[reverse.wkt](https://sourceforge.net/p/jump-pilot/bugs/494/attachment/reverse.wkt)
 (149 Bytes; application/octet-stream)


I have a simple WKT file with an attribute data (like 'proba.wkt' file) where 
the geomerty is in the second data field/column.
I have open it with the "wkt (set options)" function into a new project.
I have set the "Column containing WKT geometry" listbox to "2".
That was great: I could see the map and data.
I have saved the project as proba.jmp and I saw the
~~~
WKT-Column
2
~~~
lines in JMP file so I thought everyhing is OK, but when I tried reopen the JMP 
file I got a java.lang.Exception:
>  Field 1 is needed for geometry but [] has only 0 fields.

What was wrong...?

It's OK, I tried other way...
Let be the geometry in the first and the attribute data in the second  data 
field/column (like 'reverse.wkt' file) and open it (with "Column containing WKT 
geometry" listbox to "1" option) and save the project (reverse.jmp). There are 
the
~~~
WKT-Column
1
~~~
rows.
When I tried reopen then I got the
>  Field 0 is needed for geometry but [] has only 0 fields

exception, similar before but the index is 0...

I am afraid, the JMP files are correct but the loader have wrong about indexing 
besause it try load geometry from other column what I have set and stored in 
JMP file or what am i wrong with?




---

Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is 
subscribed to https://sourceforge.net/p/jump-pilot/bugs/

To unsubscribe from further messages, a project admin can change settings at 
https://sourceforge.net/p/jump-pilot/admin/bugs/options.  Or, if this is a 
mailing list, you can unsubscribe from the mailing list.___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel