On 19.08.2020 21:45, michael michaud wrote:
> Finally found it : you were right when you said that the database loader
> could be at fault if, by design or flaw, it did not read dates as dates.
> This comes from r6129, when you added FlexibleFeature in database loader. At
> the same time, the
Finally found it : you were right when you said that the database loader could
be at fault if, by design or flaw, it did not read dates as dates.
This comes from r6129, when you added FlexibleFeature in database loader. At
the same time, the DateConverter has been changed to always read dates
All the time, it was just more surprising and easier to notice with snap to
grid on. By experiencing with the snapping tolerance the offset seems to be
about 15 pixels.
-Jukka-
-Alkuperäinen viesti-
Lähettäjä: edgar.sol...@web.de
Lähetetty: keskiviikko 19. elokuuta 2020 17.56
do the vertices only get placed wrongly when 'snap to grid' is enabled or all
the time or ?.. ede
On 19.08.2020 14:28, Rahkonen Jukka (MML) wrote:
> Hi,
>
> Tested with OpenJUMP-20200818-r6382-PLUS with java versions Corretto 8 and
> JDK 11 on Windows. The issue appears also with
i just noticed that FlexFeature uses AttributeType.DATE, which is
java.sql.Date.class to determine if conversion is needed or not. that might
lead to conversion of java.util.Date objects which is definitely unwanted.
btw. found this commit
https://sourceforge.net/p/jump-pilot/code/6129/
where
Mike,
saving by itself is not the root problem here. this is proven by the second run
(when all dates are converted).
it is a combination of opening/editing/saving. if a data reader (eg. JML or
GeoJSON now) uses FlexibleFeature's (FF) lazy conversion, time is saved by
simply not converting
Hi,
Tested with OpenJUMP-20200818-r6382-PLUS with java versions Corretto 8 and JDK
11 on Windows. The issue appears also with OpenJUMP-20200415-r6252-PLUS. What
happens is that the tip of the digitizing tool has some sort of offset compared
with the map canvas. As a result the digitized point
A beanshell test just comparing writing shp from BasicFeature and from
FlexibleFeature.
(to be executed from the Beanshell Editor)
Attachments:
-
[test_flexible_feature.bsh](https://sourceforge.net/p/jump-pilot/bugs/_discuss/thread/62e6f051ce/6cc8/attachment/test_flexible_feature.bsh)
(1.7
Hi,
There are mails about slow parsing of JML in July 2017 and I experienced slow
parsing of dates from Spatialite in February 2019, discussion is also on the
mailing list. It seems there is a need to test your fixes also with JML and
SpatiaLite, not only with shapefiles.
-Jukka-
Lähettäjä:
There are mails about slow parsing of JML in July 2017 and I experienced slow
parsing of dates from Spatialite in February 2019, discussion is also on the
mailing list. I hope that new fixes do not cause regression in other places.
---
** [bugs:#497] Shapefile export slowed down because of
On 19.08.2020 09:25, michael michaud wrote:
> Indeed, from my tests, things are getting worst :
well. it shouldn't after all i'm trying to improve things :)
> I save my dataset to a shapefile after it has been freshly extracted from a
> database (it contains a geometry and a timestamp)
> 1.15
Jukka : you are right that shapefile store only dates, but conversion from
shapefile dates to java Date (+ time) and from java Date (+ time) to shapefile
date should be done with a fixed parser ( DbfFile.DATE_PARSER) rather than the
expensive FlexibleDateParser. Adding/truncating the time part
Perhaps parsing is implemented as it is also because dbf and thus shapefile
supports DATE but not DATETIME and conversion into strings is really needed
only if time values contain also hours and so on?
---
** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**
Indeed, from my tests, things are getting worst :
I save my dataset to a shapefile after it has been freshly extracted from a
database (it contains a geometry and a timestamp)
1.15 : 1st save : 55s
2nd save < 1s
r6382 : 1st save : 188s!
2nd save < 1s
Another thing
14 matches
Mail list logo
