Hi Michaël,
Don't be sorry, it was quite good to understand how it works.
The changes I made seem to fix the part of makeValid which tests if the
"geometry" dimension (based on CoordinateSequence, not the geometry
dimension itself). If the dimension is 4, it calls restoreDim4 as
expected. The
Eric,Not sure I understand your proposition. There is now a function of OpenJUMP-core using this MakeValidOp. If we move it to another project, it will make the build a bit more difficult isn't it ?About tests, you're completely right. I'm often lazy and just push a few tests in the main() of the
Hi Michaël,
The idea behind openjump-migration is initially to test the SVN to Git
migration and the JTS update. If we start updating some specific code or
creating a test part, it is going to become something else, and it will
be probably difficult to reproduce all these steps when/if you dec
The migration, as previously discussed (SVN from Git + JTS 1.17), is now
complete. See:
https://github.com/openjump-gis/openjump-migration/commit/3c24bce2bc6c69d2c786af5c9c0a4737b07666ad
I'm going to try completing the documentation asap, and adding a
automated build configuration. I'll let you
OK, I understand,Maybe good to have a separate project to test it. I firstly thought a fix on my local disk would be enough, but sharing it on github is a good idea as this class is also used by OrbisGIS project and hopefully, it will make its way to jts (there is already an implementation in geo
Revision: 6379
http://sourceforge.net/p/jump-pilot/code/6379
Author: edso
Date: 2020-08-18 18:14:31 + (Tue, 18 Aug 2020)
Log Message:
---
add a Log.info() on the time it took to save file
helpful for debugging file writing
using level info so users do not need to switch
sorry Mike, can't reproduce it.
actually writing is magnitudes faster than reading on my laptop. see
[INFO] 20:05:45.910 Reading 'test_date.shp' took 6.64s.
[INFO] 20:05:47.011 Done. Current committed
memory:plugin.AbstractPlugIn.executing = Executing199 MB
[INFO] 20:05:47.013 Activating Select
ok, got it. SHP reader does not seem to use lazy date parsing via
FlexibleDateParser. converting your set to JML and tryinf to save that involves
FlexibleDateParser and shows the symptoms you observed.
..ede
On 18.08.2020 20:24, ede wrote:
> sorry Mike, can't reproduce it.
>
> actually writing
Revision: 6380
http://sourceforge.net/p/jump-pilot/code/6380
Author: edso
Date: 2020-08-18 19:19:01 + (Tue, 18 Aug 2020)
Log Message:
---
changing a debug out to trace because of it's level of detail is slowing down
loading massively
Modified Paths:
--
Revision: 6381
http://sourceforge.net/p/jump-pilot/code/6381
Author: edso
Date: 2020-08-18 19:26:30 + (Tue, 18 Aug 2020)
Log Message:
---
speedup FlexibleDateParser.parse() by moving successful Parsers to the front of
the list of Parsers to try
Modified Paths:
just committed r6381 which speeds up FlexibleDateParser by prefering successful
DateFormatters (see log below). please test.
other observations.
1. saving the SHP data immediately again is lightning speed fast. not sure why.
2. sometimes writing with the new "Save Dataset as (testing)" dialog fai
Revision: 6382
http://sourceforge.net/p/jump-pilot/code/6382
Author: michaudm
Date: 2020-08-18 21:02:19 + (Tue, 18 Aug 2020)
Log Message:
---
Deactivate 2 tests on FlexibleDateParser
Modified Paths:
--
core/trunk/src/jumptest/junit/FlexibleDateParserTest
Hi Ede,
Seems to be a nice tweak but something is still wrong : the first save is still
very slow.
Seems that the second save of a dataset benefits your optimization, but the
save operation on a freshly imported/extracted dataset is still long.
Also there is something I don't understand : writing
On 18.08.2020 23:42, michael michaud wrote:
> Hi Ede,
> Seems to be a nice tweak but something is still wrong : the first save is
> still very slow.
surely it's faster than before, or? before it tried 125 parser for each entry
before succeeding. now this only happens on the first try and then th
14 matches
Mail list logo
