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

2020-08-20 Thread jump-pilot-svn--- via Jump-pilot-devel 
Revision: 6383
  http://sourceforge.net/p/jump-pilot/code/6383
Author:   michaudm
Date: 2020-08-20 06:59:27 + (Thu, 20 Aug 2020)
Log Message:
---
Read dates as Date from database, update postgresql and sqlite jdbc drivers

Modified Paths:
--
core/trunk/ChangeLog
core/trunk/pom.xml

core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java

Added Paths:
---
core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.32.3.2.jar

Removed Paths:
-
core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.20.0.jar

Modified: core/trunk/ChangeLog
===
--- core/trunk/ChangeLog2020-08-18 21:02:19 UTC (rev 6382)
+++ core/trunk/ChangeLog2020-08-20 06:59:27 UTC (rev 6383)
@@ -4,6 +4,9 @@
 # 3. be concise but convey the change in a way that ordinary users understand
 #< 80 chars 
-->#
 
+2020-08-20 mmichaud 
+  * Fix regression : read dates from database as java.util.Date, not String
+  * update postgresql and sqlite jdbc drivers
 
 2020-08-17 Giuseppe Aruta
   * Added new tools in SextanteGIS :

Deleted: core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.20.0.jar
===
(Binary files differ)

Added: core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.32.3.2.jar
===
(Binary files differ)

Index: core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.32.3.2.jar
===
--- core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.32.3.2.jar2020-08-18 
21:02:19 UTC (rev 6382)
+++ core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.32.3.2.jar2020-08-20 
06:59:27 UTC (rev 6383)

Property changes on: core/trunk/lib/plus/dbdatastore/sqlite-jdbc-3.32.3.2.jar
___
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Modified: core/trunk/pom.xml
===
--- core/trunk/pom.xml  2020-08-18 21:02:19 UTC (rev 6382)
+++ core/trunk/pom.xml  2020-08-20 06:59:27 UTC (rev 6383)
@@ -918,7 +918,7 @@
 
 org.postgresql
 postgresql
-9.4.1208.jre6
+42.2.14
 compile
 
 

Modified: 
core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java
===
--- 
core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java
2020-08-18 21:02:19 UTC (rev 6382)
+++ 
core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java
2020-08-20 06:59:27 UTC (rev 6383)
@@ -118,10 +118,10 @@
 public AttributeType getType() { return AttributeType.DATE; }
 public Object getValue(ResultSet rs, int columnIndex) throws 
SQLException {
   // always return string for dates and let FlexibleFeature 
convert later during runtime
-  return rs.getString(columnIndex);
+  //return rs.getString(columnIndex);
 //Object ret = null;
 //try {
-//ret = rs.getTimestamp(columnIndex);
+  return rs.getTimestamp(columnIndex);
 //if (rs.wasNull()) return null;
 //} catch (Exception e) {
 //// try to read date from string, as some SpatialDatabases 
like SQLite



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

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

2020-08-20 Thread jump-pilot-svn--- via Jump-pilot-devel 
Revision: 6384
  http://sourceforge.net/p/jump-pilot/code/6384
Author:   michaudm
Date: 2020-08-20 07:17:48 + (Thu, 20 Aug 2020)
Log Message:
---
Revert the fallback to FlexibleDateParser if rs.getTimestamp fails (useful for 
sqlite ?)

Modified Paths:
--
core/trunk/ChangeLog

core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java

Modified: core/trunk/ChangeLog
===
--- core/trunk/ChangeLog2020-08-20 06:59:27 UTC (rev 6383)
+++ core/trunk/ChangeLog2020-08-20 07:17:48 UTC (rev 6384)
@@ -5,7 +5,7 @@
 #< 80 chars 
-->#
 
 2020-08-20 mmichaud 
-  * Fix regression : read dates from database as java.util.Date, not String
+  * #497 : read dates from database as java.util.Date, not String
   * update postgresql and sqlite jdbc drivers
 
 2020-08-17 Giuseppe Aruta

Modified: 
core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java
===
--- 
core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java
2020-08-20 06:59:27 UTC (rev 6383)
+++ 
core/trunk/src/com/vividsolutions/jump/datastore/jdbc/ValueConverterFactory.java
2020-08-20 07:17:48 UTC (rev 6384)
@@ -119,22 +119,22 @@
 public Object getValue(ResultSet rs, int columnIndex) throws 
SQLException {
   // always return string for dates and let FlexibleFeature 
convert later during runtime
   //return rs.getString(columnIndex);
-//Object ret = null;
-//try {
-  return rs.getTimestamp(columnIndex);
-//if (rs.wasNull()) return null;
-//} catch (Exception e) {
-//// try to read date from string, as some SpatialDatabases 
like SQLite
-//// can store DATE type in string
-//FlexibleDateParser parser = new FlexibleDateParser();
-//try {
-//ret = parser.parse(rs.getString(columnIndex), false);
-//} catch (Exception ee) {
-//System.err.println("cannot parse date value: \"" + 
rs.getString(columnIndex)
-//+ "\" Defaulting to null.\n" + ee.getMessage());
-//}
-//}
-//return ret;
+  Object ret = null;
+  try {
+  ret = rs.getTimestamp(columnIndex);
+  if (rs.wasNull()) return null;
+  } catch (Exception e) {
+  // try to read date from string, as some SpatialDatabases 
like SQLite
+  // can store DATE type in string
+  FlexibleDateParser parser = new FlexibleDateParser();
+  try {
+  ret = parser.parse(rs.getString(columnIndex), false);
+  } catch (Exception ee) {
+  System.err.println("cannot parse date value: \"" + 
rs.getString(columnIndex)
+  + "\" Defaulting to null.\n" + ee.getMessage());
+  }
+  }
+  return ret;
 }
 }
 



___
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] Re: #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread michael michaud via Jump-pilot-devel 
OK, changed it. I'm not a spatialite user, but I'll try to configure a database 
to do more tests.
I also upgraded postgresql and sqlite jdbc drivers.

As far as I understood, the spatialite database has no date type and getting 
date or timestamp from it is still very hazardeous 
(https://github.com/xerial/sqlite-jdbc/issues/88). I think  the fallback to 
FlexDateParser is necessary for this reason, but it may lead to a performance 
regression except if your patch on the FlexDateParser can really place the good 
parser at first place (until now, I could not measure the impact of you change 
as the first save operation from a Dataset made of FlexibleFeatures was still 
long) .
For now :
r 6383 just restored the read of dates from Database as java.util.Date
r 6384 restored the fallback to the possibly slow FlexibleDateParser in case 
the database driver fails to read the date with rs.getTimestamp method


---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Wed Aug 19, 2020 07:45 PM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

[JPP-Devel] [jump-pilot:bugs] #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread Jukka Rahkonen via Jump-pilot-devel 
Handling dates in SQLite generally is somehow special, see for example 
https://www.sqlitetutorial.net/sqlite-date/.
I believe that in SpatiaLite the dates/times are stored either as strings or 
Julian numbers it is up to client application to know how to parse the data. 
GeoPackage is using DATE as
ISO-8601 date string in the form -MM-DD encoded in either UTF-8 or UTF-16 
and stored as SQLite TEXT.
and DATETIME as
ISO-8601 date/time string in the form -MM-DDTHH:MM:SS.SSSZ with T separator 
character and Z suffix for coordinated universal time (UTC) encoded in either 
UTF-8 or UTF-16 and stored as SQLite TEXT.

As a helper for the clients the CREATE TABLE that can be read from the database 
may contain a hint like CREATE TABLE 'timetest' ( "ogc_fid" INTEGER PRIMARY KEY 
AUTOINCREMENT, 'time' DATE, 'attr' VARCHAR(1), "GEOMETRY" POINT). That info 
should always be included in geopackages.

Parsing dates as strings from Spatialite may be the best alternative and it is 
OK for Geopackage as well, even bacause of explicit definitions it is possible 
to read dates and datetimes from Geopackage right into correct datatypes.


---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 07:19 AM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

[JPP-Devel] [jump-pilot:bugs] Re: #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread ede via Jump-pilot-devel 
On 20.08.2020 09:19, michael michaud wrote:
> OK, changed it. I'm not a spatialite user, but I'll try to configure a 
> database to do more tests.
> I also upgraded postgresql and sqlite jdbc drivers.

ok. not sure that i like the FlexParser fallback though. this can get really 
slow. as you noticed.

i'd say users are more patient when saving/editing than while waiting for data 
to appear. hence converting them lazily should suffice.

> As far as I understood, the spatialite database has no date type and getting 
> date or timestamp from it is still very hazardeous 
> (https://github.com/xerial/sqlite-jdbc/issues/88). I think  the fallback to 
> FlexDateParser is necessary for this reason, but it may lead to a performance 
> regression except if your patch on the FlexDateParser can really place the 
> good parser at first place (until now, I could not measure the impact of you 
> change as the first save operation from a Dataset made of FlexibleFeatures 
> was still long) .

well, of course it's still slower. but 250x that slow as when the fitting 
parser is found in the 250th place in the list every time ;)

> For now :
> r 6383 just restored the read of dates from Database as java.util.Date

our Attribute Class says we need java.sql.Date, which is it? should we losen 
the requirement to java.util.Date?

> r 6384 restored the fallback to the possibly slow FlexibleDateParser in case 
> the database driver fails to read the date with rs.getTimestamp method

will put some suggestions wrt. Spatialite in the answer to Jukka's details on 
how date/times should be saved in Spatialite. ..ede

>
>
> ---
>
> ** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**
>
> **Status:** open
> **Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
> **Last Updated:** Wed Aug 19, 2020 07:45 PM UTC
> **Owner:** michael michaud
>
>
> Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
> with version 1.15 lasted more than 20 minutes.
> Most of the time is used by FlexibleDateParser.parse().
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in 
> 
>
>
>
> To unsubscribe from further messages, please visit 
> 
>



---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 08:21 AM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

[JPP-Devel] [jump-pilot:bugs] Re: #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread ede via Jump-pilot-devel 
On 20.08.2020 10:21, Jukka Rahkonen wrote:
> Handling dates in SQLite generally is somehow special, see for example 
> https://www.sqlitetutorial.net/sqlite-date/.
> I believe that in SpatiaLite the dates/times are stored either as strings or 
> Julian numbers it is up to client application to know how to parse the data. 
> GeoPackage is using DATE as
> ISO-8601 date string in the form -MM-DD encoded in either UTF-8 or UTF-16 
> and stored as SQLite TEXT.
> and DATETIME as
> ISO-8601 date/time string in the form -MM-DDTHH:MM:SS.SSSZ with T 
> separator character and Z suffix for coordinated universal time (UTC) encoded 
> in either UTF-8 or UTF-16 and stored as SQLite TEXT.
>
> As a helper for the clients the CREATE TABLE that can be read from the 
> database may contain a hint like CREATE TABLE 'timetest' ( "ogc_fid" INTEGER 
> PRIMARY KEY AUTOINCREMENT, 'time' DATE, 'attr' VARCHAR(1), "GEOMETRY" POINT). 
> That info should always be included in geopackages.
>
> Parsing dates as strings from Spatialite may be the best alternative and it 
> is OK for Geopackage as well, even bacause of explicit definitions it is 
> possible to read dates and datetimes from Geopackage right into correct 
> datatypes.


yeah, it reads as if Sqlite does not handle dates/times at all
https://stackoverflow.com/questions/5425557/sqlite-jdbc-rs-getdate-gettimestamp-etc-all-return-wrong-valueshttps://stackoverflow.com/questions/5425557/sqlite-jdbc-rs-getdate-gettimestamp-etc-all-return-wrong-values

so how about we always fetch it as String and parse the 3 formats given above? 
and only if that fails it is given to FlexParser, preferably via FlexFeature 
becuase of loading time delay.

could someone build me a test dataset?

..ede


---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 08:21 AM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

[JPP-Devel] [jump-pilot:bugs] Re: #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread ede via Jump-pilot-devel 
a little off but still on topic :)
https://stackoverflow.com/questions/2305973/java-util-date-vs-java-sql-date

interesting read.. ede


---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 08:21 AM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

[JPP-Devel] OpenJUMP migration documentation

2020-08-20 Thread Eric 

Hi,

The first part of this documentation is now online: 
https://github.com/openjump-gis/openjump-migration-doc


It focuses only on the migration from SVN to Git.

Before migrating, the reading of this article could be useful as it 
contains some good practice tips:

https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git

Eric


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

Re: [JPP-Devel] OpenJUMP migration documentation

2020-08-20 Thread Eric 

Just added the documentation to update JTS from 1.14 to 1.17.

Eric

On 20/08/2020 13:42, Eric wrote:

Hi,

The first part of this documentation is now online: 
https://github.com/openjump-gis/openjump-migration-doc


It focuses only on the migration from SVN to Git.

Before migrating, the reading of this article could be useful as it 
contains some good practice tips:
https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git 



Eric




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

Re: [JPP-Devel] OpenJUMP migration documentation

2020-08-20 Thread Michaud Michael 


Hi,Big thanks for this work Eric, seems to be very well documented.I think we should take advantage of this work and proceed to a more definitive migration without waiting too much.What about listing the tickets or tasks we want to fix before migration (if possible something we can achieve within a few weeks). Then we could make a new release and concentrate on the migration. Any other proposal somebody ?Michaëlenvoyé : 20 août 2020 à 17:58de : Eric à : jump-pilot-devel@lists.sourceforge.netobjet : Re: [JPP-Devel] OpenJUMP migration documentationJust added the documentation to update JTS from 1.14 to 1.17.EricOn 20/08/2020 13:42, Eric wrote:Hi,The first part of this documentation is now online: https://github.com/openjump-gis/openjump-migration-docIt focuses only on the migration from SVN to Git.Before migrating, the reading of this article could be useful as it contains some good practice tips:https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git Eric___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

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

[JPP-Devel] [jump-pilot:bugs] #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread ede via Jump-pilot-devel 
- **Milestone**:  --> OJ 1.16



---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Milestone:** OJ 1.16
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 08:21 AM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

[JPP-Devel] [jump-pilot:bugs] #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread ede via Jump-pilot-devel 
- **Milestone**: OJ-1.16 --> undecided



---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Milestone:** undecided
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 05:47 PM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

[JPP-Devel] [jump-pilot:bugs] #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread ede via Jump-pilot-devel 
- **Milestone**: undecided --> final_OJ



---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Milestone:** final_OJ
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 05:55 PM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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

Re: [JPP-Devel] OpenJUMP migration documentation

2020-08-20 Thread edgar . soldin 
On 20.08.2020 19:08, Michaud Michael wrote:
> Hi,
>
> Big thanks for this work Eric, seems to be very well documented.

yup, impressively well documented!

> I think we should take advantage of this work and proceed to a more definitive
> migration without waiting too much.

true. but we should still put out a final "stable" because it'll probably take 
some time to adapt all those missing extensions.

> What about listing the tickets or tasks we want to fix before migration (if
> possible something we can achieve within a few weeks). Then we could make a 
> new
> release and concentrate on the migration.

agreed. we should at least prioritize. let me try to set up a milestone in the 
bug tracker.

sorry for spamming the list, but setting up the searchable milestone on sf.net 
was a bit bothersome.

we have 36 open bugs, which can now be assigned to a OJ_1.16 milestone now. 
when that's done we can search them on the left side via 'Open Tickets for OJ 
1.16' and fix em one by one.

hands up. who want's to tag'em?

> Any other proposal somebody ?

not me :).. ede

>
> Michaël
>
>> envoyé : 20 août 2020 à 17:58
>> de : Eric 
>> à : jump-pilot-devel@lists.sourceforge.net
>> objet : Re: [JPP-Devel] OpenJUMP migration documentation
>>
>>
>> Just added the documentation to update JTS from 1.14 to 1.17.
>>
>> Eric
>>
>> On 20/08/2020 13:42, Eric wrote:
>>
>>> Hi,
>>>
>>> The first part of this documentation is now online:
>>> https://github.com/openjump-gis/openjump-migration-doc
>>>
>>> It focuses only on the migration from SVN to Git.
>>>
>>> Before migrating, the reading of this article could be useful as it
>>> contains some good practice tips:
>>> https://docs.microsoft.com/en-us/azure/devops/learn/git/centralized-to-git
>>>
>>>
>>> Eric
>>>
>>
>>
>> ___
>> Jump-pilot-devel mailing list
>> Jump-pilot-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>>
>
>
>
> ___
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>



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

[JPP-Devel] sqlite database

2020-08-20 Thread Michaud Michael 


Hi Jukka, NicolasDo you know the state of sqlite in OpenJUMP ? I've tried to load a table from a sqlite database for a few hours without success.I tried with OJ 1.14, 1.15, last snapshot, and I tried to load from a database created from a shapefile with spatialite-gui or from a database created from QGis as a spatialite or as geopackage. Maybe I omitted something obvious, I'm not familiar with sqlite.For all my tests, I get the same error after I have choosen the table and clicked on finish. The error seems related to geometry retrieval or index retrieval :java.lang.NullPointerExceptionat com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.buildSpatialIndexFilter(SpatialiteSQLBuilder.java:157)at com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.buildBoxFilter(SpatialiteSQLBuilder.java:116)at com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.getSQL(SpatialiteSQLBuilder.java:39)Thanks for the help,Michaël

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

Re: [JPP-Devel] sqlite database

2020-08-20 Thread Rahkonen Jukka (MML) 
Geopackage with 5.4 million polygonz geometries opens with 
OpenJUMP-20200818-r6382-PLUS in 49 seconds. There is a trick: the extent of the 
table is not recognized right so adding table into a new empty project does not 
show anything and zoom to layer does not work as it should. Digitize one 
feature within the true extents, or open some other data first and adding 
layers from geopackage should work.

If you do not have success with your own data I can arrange some test data.

-Jukka-

Lähettäjä: Michaud Michael 
Lähetetty: torstai 20. elokuuta 2020 21.24
Vastaanottaja: OpenJump develop and use 
Aihe: [JPP-Devel] sqlite database


Hi Jukka, Nicolas

Do you know the state of sqlite in OpenJUMP ? I've tried to load a table from a 
sqlite database for a few hours without success.

I tried with OJ 1.14, 1.15, last snapshot, and I tried to load from a database 
created from a shapefile with spatialite-gui or from a database created from 
QGis as a spatialite or as geopackage. Maybe I omitted something obvious, I'm 
not familiar with sqlite.

For all my tests, I get the same error after I have choosen the table and 
clicked on finish. The error seems related to geometry retrieval or index 
retrieval :

java.lang.NullPointerException
at 
com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.buildSpatialIndexFilter(SpatialiteSQLBuilder.java:157)
at 
com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.buildBoxFilter(SpatialiteSQLBuilder.java:116)
at 
com.vividsolutions.jump.datastore.spatialite.SpatialiteSQLBuilder.getSQL(SpatialiteSQLBuilder.java:39)

Thanks for the help,

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] Re: #497 Shapefile export slowed down because of FlexibleDateParser

2020-08-20 Thread ede via Jump-pilot-devel 
just was browsing the sqlite jdbc sources and thought, how do they deal with 
date/time/timestamps, if at all. well what they do is this

JDBC3ResultSet.getDate()
https://github.com/xerial/sqlite-jdbc/blob/master/src/main/java/org/sqlite/jdbc3/JDBC3ResultSet.java#L524

you may also search for getTimestamp() and getTime(). we might learn something 
from the approach there ;).. ede


On 20.08.2020 11:12, ede wrote:
> a little off but still on topic :)
> https://stackoverflow.com/questions/2305973/java-util-date-vs-java-sql-date
>
> interesting read.. ede
>
>
> ---
>
> ** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**
>
> **Status:** open
> **Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
> **Last Updated:** Thu Aug 20, 2020 08:21 AM UTC
> **Owner:** michael michaud
>
>
> Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
> with version 1.15 lasted more than 20 minutes.
> Most of the time is used by FlexibleDateParser.parse().
>
>
> ---
>
> Sent from sourceforge.net because you indicated interest in 
> 
>
>
>
> To unsubscribe from further messages, please visit 
> 
>



---

** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**

**Status:** open
**Milestone:** OJ_1.16
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Thu Aug 20, 2020 06:00 PM UTC
**Owner:** michael michaud


Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb) 
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().


---

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