Re: [JPP-Devel] batik upgraded
Hi Ede, Michaël
Following Michaël's test I also was able to do a test using 3 versions of
OpenJUMP
a) OpenJUMP 1.5 last stable realize
b) OpenJUMP 6363. I choose this version because I grouped "Save view"
plugins into a unique menu
("Save view") with the option to choose type (TIFF, PNG and SVG). I
extended to svg the
option to save at a defined scale
c) OpenJUMP 6370, the last NB realize where Ede upgraded batik libraries
I used as test files one vector file, one image file,loaded as
referencedImageLayer (both
using Open->file menu), and one DEM file loaded as RasterImageLayer (using
Open->Raster Image (sextante)
menu.
Test files and SVG output are available here:
https://sourceforge.net/projects/opensit/files/Test%20file/Export%20to%20SVG/
These are the problems (the first one already known) and bugs that I found
(not only on SVG).
*On saving a project file*.
ReferencedImageLayer must be saved as a vector layer (SHP or JML) otherwise
it will not be saved into the project file.
*On loading project files saved with different versions of OpenJUMP*.
There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
saving/loading project files.
a) OpenJUMP 1.5 freezes on loading project files saved at least with
OpenJUMP 6363 and 6370
The console (I use Linux) doesn't show any warning.
b) OpenJUMP 6363 and 6370 cannot load project files saved at least with
OpenJUMP 1.5 .
The console doesn't show any warning.
c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and vice
versa
3)* On saving SVG*
a) *Saving SVG using embedded Save view plugin*
OpenJUMP 1.5 and OpenJUMP 6363 save the view with all the three layers if I
don't modify any
parameters on Save dialog. On the other hand, modifing the scale parameters
on save dialog,
RasterImageLayer is not saved on SVG file
OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)
b)* Saving SVG using CadPlann print plugin*
OpenJUMP 1.5 and OpenJUMP 6363. While ReferencedImageLayers and
VectorLayers are
saved at the correct scale and position, RasterImageLayers are rescaled
and, possibly, shifted
from their original position, compared to OpenJUMP view.
OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)
Saving SVG with OpenJUMP 6370 can be corrected using the newer batik
libraries. I which approach we need to fix the scaling problems
of RasterImageLayers.
I will open a bug ticket for the problem about *loading project files saved
with different versions of OpenJUMP.* It looks quite severe
Best regards
Peppe
Il giorno sab 8 ago 2020 alle ore 22:16 Michaud Michael <
m.michael.mich...@orange.fr> ha scritto:
> Hi Ede,
>
> I finally found some time and get noticeable differences between last
> revision and 1.15.
>
> I just tested export image to svg and export map to svg from cadplan (I
> don't know other places where svg is used).
>
> Prepare a map wit a sextante raster and some vectors
>
> Export the view to a file, choose svg :
>
> - get the same thing on 1.15 and last revision : vectors but no image
>
> Export map from cadplan
>
> - cadplan with external renderer : get nothing, file is even not exported
> (neither in 1.15 nor with last revision)
>
> - cadplan ISA renderer : get vector and raster with a scale problem on
> 1.15, get nothing with last release
>
> - cadplan core renderer : get vector and raster on 1.15, get nothing with
> last release
>
> => I couldn't get svg map from cadplan plugin from last release, did you ?
>
>
> Michaël
>
>
>
> envoyé : 6 août 2020 à 14:46
> de : edgar.sol...@web.de
> à : jump-pilot-devel@lists.sourceforge.net
> objet : Re: [JPP-Devel] batik upgraded
>
>
> a quick test of both did not reveal any bugs. how about on your sides?
> ..ede
>
> On 05.08.2020 16:14, Giuseppe Aruta wrote:
>
> Thanks Ede,
> AFAIR also both print plugins have dependencies to batik classes
> Peppe
>
> Il giorno mer 5 ago 2020 alle ore 15:19 edgar.sol...@web.de>> ha scritto:
>
> hey All,
>
> had to touch batik, as it was missing some classes in trunk/lib/batik.jar
> after Peppe added AdditionalResultsIO. maven already had the proper batik
> components defined that's why the snapshot builds went fine.
>
> while at it i noticed that we were using a quite old batik version and
> upgraded it. looks good to me but please test and come back if something
> breaks horribly.
>
> sunshine all over.. (sweating) ede
>
> Forwarded Message
> Subject: [JPP-Devel] SVN: [6369] core/trunk
> Date: Wed, 05 Aug 2020 12:50:50 +
> From: jump-pilot-svn--- via Jump-pilot-devel <
> jump-pilot-devel@lists.sourceforge.net jump-pilot-devel@lists.sourceforge.net>>
> Reply-To: OpenJump develop and use >
> To: jump-pilot-devel@lists.sourceforge.net jump-pilot-devel@lists.sourceforge.net>
> CC: jump-pilot-...@lists.sourceforge.net jump-pilot-...@lists.sourceforge.net>
>
> Revision: 6369
> http://sourceforge.net/p/jump-pilot/code/6369
> A
Re: [JPP-Devel] batik upgraded
For CadPlan SVG export. I only used ISA renderer
Il giorno dom 9 ago 2020 alle ore 14:03 Giuseppe Aruta <
giuseppe.ar...@gmail.com> ha scritto:
> Hi Ede, Michaël
>
> Following Michaël's test I also was able to do a test using 3 versions of
> OpenJUMP
> a) OpenJUMP 1.5 last stable realize
> b) OpenJUMP 6363. I choose this version because I grouped "Save view"
> plugins into a unique menu
> ("Save view") with the option to choose type (TIFF, PNG and SVG). I
> extended to svg the
> option to save at a defined scale
> c) OpenJUMP 6370, the last NB realize where Ede upgraded batik libraries
>
> I used as test files one vector file, one image file,loaded as
> referencedImageLayer (both
> using Open->file menu), and one DEM file loaded as RasterImageLayer (using
> Open->Raster Image (sextante)
> menu.
> Test files and SVG output are available here:
>
> https://sourceforge.net/projects/opensit/files/Test%20file/Export%20to%20SVG/
>
> These are the problems (the first one already known) and bugs that I found
> (not only on SVG).
>
> *On saving a project file*.
> ReferencedImageLayer must be saved as a vector layer (SHP or JML)
> otherwise it will not be saved into the project file.
>
> *On loading project files saved with different versions of OpenJUMP*.
> There is a break after OpenJUMP 1.5 and before OpenJUMP 6363 on
> saving/loading project files.
>a) OpenJUMP 1.5 freezes on loading project files saved at least with
> OpenJUMP 6363 and 6370
> The console (I use Linux) doesn't show any warning.
>b) OpenJUMP 6363 and 6370 cannot load project files saved at least
> with OpenJUMP 1.5 .
> The console doesn't show any warning.
> c) OpenJUMP 6363 can load project files saved with OpenJUMP 6370 and
> vice versa
>
> 3)* On saving SVG*
>
> a) *Saving SVG using embedded Save view plugin*
> OpenJUMP 1.5 and OpenJUMP 6363 save the view with all the three layers if
> I don't modify any
> parameters on Save dialog. On the other hand, modifing the scale
> parameters on save dialog,
> RasterImageLayer is not saved on SVG file
> OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)
>
> b)* Saving SVG using CadPlann print plugin*
> OpenJUMP 1.5 and OpenJUMP 6363. While ReferencedImageLayers and
> VectorLayers are
> saved at the correct scale and position, RasterImageLayers are rescaled
> and, possibly, shifted
> from their original position, compared to OpenJUMP view.
> OpenJUMP 6370 saves an empty SVG file (none of the layers are displayed)
>
> Saving SVG with OpenJUMP 6370 can be corrected using the newer batik
> libraries. I which approach we need to fix the scaling problems
> of RasterImageLayers.
> I will open a bug ticket for the problem about *loading project files
> saved with different versions of OpenJUMP.* It looks quite severe
> Best regards
> Peppe
>
> Il giorno sab 8 ago 2020 alle ore 22:16 Michaud Michael <
> m.michael.mich...@orange.fr> ha scritto:
>
>> Hi Ede,
>>
>> I finally found some time and get noticeable differences between last
>> revision and 1.15.
>>
>> I just tested export image to svg and export map to svg from cadplan (I
>> don't know other places where svg is used).
>>
>> Prepare a map wit a sextante raster and some vectors
>>
>> Export the view to a file, choose svg :
>>
>> - get the same thing on 1.15 and last revision : vectors but no image
>>
>> Export map from cadplan
>>
>> - cadplan with external renderer : get nothing, file is even not exported
>> (neither in 1.15 nor with last revision)
>>
>> - cadplan ISA renderer : get vector and raster with a scale problem on
>> 1.15, get nothing with last release
>>
>> - cadplan core renderer : get vector and raster on 1.15, get nothing with
>> last release
>>
>> => I couldn't get svg map from cadplan plugin from last release, did you ?
>>
>>
>> Michaël
>>
>>
>>
>> envoyé : 6 août 2020 à 14:46
>> de : edgar.sol...@web.de
>> à : jump-pilot-devel@lists.sourceforge.net
>> objet : Re: [JPP-Devel] batik upgraded
>>
>>
>> a quick test of both did not reveal any bugs. how about on your sides?
>> ..ede
>>
>> On 05.08.2020 16:14, Giuseppe Aruta wrote:
>>
>> Thanks Ede,
>> AFAIR also both print plugins have dependencies to batik classes
>> Peppe
>>
>> Il giorno mer 5 ago 2020 alle ore 15:19 > edgar.sol...@web.de>> ha scritto:
>>
>> hey All,
>>
>> had to touch batik, as it was missing some classes in trunk/lib/batik.jar
>> after Peppe added AdditionalResultsIO. maven already had the proper batik
>> components defined that's why the snapshot builds went fine.
>>
>> while at it i noticed that we were using a quite old batik version and
>> upgraded it. looks good to me but please test and come back if something
>> breaks horribly.
>>
>> sunshine all over.. (sweating) ede
>>
>> Forwarded Message
>> Subject: [JPP-Devel] SVN: [6369] core/trunk
>> Date: Wed, 05 Aug 2020 12:50:50 +
>> From: jump-pilot-svn--- via Jump-pilot-devel <
>> jump-pilot-devel@lists.sourceforge.net > jump-pilot-devel@lists.sourceforge.
Re: [JPP-Devel] batik upgraded
On 09.08.2020 14:06, Giuseppe Aruta wrote: > I will open a bug ticket for the problem about /loading project files saved > with different versions of OpenJUMP./ It looks quite severe just to make sure. you're talking about OJ 1.15 (latest release) vs. latest snapshot right? ..ede ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] batik upgraded
On 08.08.2020 22:15, Michaud Michael wrote: > Hi Ede, hey Mike and All, hope all is well > I finally found some time and get noticeable differences between last > revision and 1.15. that's good as i lack the experience of what is expected from the corresponding extensions > I just tested export image to svg and export map to svg from cadplan (I don't > know other places where svg is used). > > Prepare a map wit a sextante raster and some vectors can you provide a test dataset? i just drew a polygon and checked if the svg corresponded. > Export the view to a file, choose svg : > - get the same thing on 1.15 and last revision : vectors but no image wasn't aware that SVG exports were supposed to contain images as well. good to know. > Export map from cadplan > > - cadplan with external renderer : get nothing, file is even not exported > (neither in 1.15 nor with last revision) > > - cadplan ISA renderer : get vector and raster with a scale problem on 1.15, > get nothing with last release > > - cadplan core renderer : get vector and raster on 1.15, get nothing with > last release > > => I couldn't get svg map from cadplan plugin from last release, did you ? > well i quickly checked SVG exports of a polygon layer with all 3 "printers" but obviously that didn't suffice. after reading Peppes report as well i'd say well it was worth a try ;) looks like it is time to roll back to batik 1.6 , at least for now. do i hear differing opinions? ..ede ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] batik upgraded
Yes 1.5 ->1.15 Il giorno dom 9 ago 2020 alle ore 14:25 ha scritto: > On 09.08.2020 14:06, Giuseppe Aruta wrote: > > I will open a bug ticket for the problem about /loading project files > saved with different versions of OpenJUMP./ It looks quite severe > > just to make sure. you're talking about OJ 1.15 (latest release) vs. > latest snapshot right? > > ..ede > > > ___ > 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] OJ 2.x Was:Re: JTS update: first experiments
hey Eric, welcome to the team! see my answers below On 07.08.2020 20:55, Eric wrote: > 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/ yeah, that's kind of a backup in case repos disappear which as you correctly determined happened since the last clean up (ages ago;) > 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. planned to move it to the current snapshot build machine at some point, as it holds the latest and most current dependencies of course. but never needed to, so here we are. > > 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. which is the main obstacle. the only clean solution i see is to branch out a new OJ 2.x that initially will break compatibility to all external plugins. that's the bad news. the good news is that this forces us to retouch pretty much all of them and during this effort we might eventually come up with a working plugin manager after all. >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. yeah, probably not. deegree2 is afaics used primarily or exclusively for the WFS extension and i remember checking out deegree3 as a drop in for deegree2 but failing miserably. that's why i stuck with deegree2 happy to have at least a working WFS extension for the time being. but again, we can remove WFS from core for OJ 2.x and come up with a working extension later (if at all). > 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, that corresponds to my findings when trying to find a solution to the package renaming dilemma jts created in 2018. we talked about it on the ml but didn't find a solution https://sourceforge.net/p/jump-pilot/mailman/jump-pilot-devel/thread/CA%2BALWNw%3DBfuQGjNLuOPgxU%2BBz7tcB5FeytomPVqFe9M5Sbh1hQ%40mail.gmail.com/#msg36283823 or https://sourceforge.net/p/jump-pilot/mailman/search/?q=%22jts+1.15%22&limit=250&page=0&sort=posted_date%20desc > - 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, how do you figure? com.vividsolutions.jump.io.geojson was written by myself from scratch utilizing google's json-simple . it holds no dependency apart from the jts geometry code. maybe myself placing it in this package has mislead you ;) > - 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, agreed > > 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 agai
[JPP-Devel] SVN: [6371] plug-ins/CsvDriver/trunk
Revision: 6371
http://sourceforge.net/p/jump-pilot/code/6371
Author: michaudm
Date: 2020-08-09 17:49:20 + (Sun, 09 Aug 2020)
Log Message:
---
#494 : hu i18n file + wkt loader accepts csv extension (v 1.1.0)
Modified Paths:
--
plug-ins/CsvDriver/trunk/build.xml
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/AutoCSVFile.java
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/CSVDataSource.java
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/CSVDriverConfiguration.java
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/CSVFile.java
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/FieldSeparator.java
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/SaveCSVFileDataSourceQueryChooser.java
Modified: plug-ins/CsvDriver/trunk/build.xml
===
--- plug-ins/CsvDriver/trunk/build.xml 2020-08-05 13:45:55 UTC (rev 6370)
+++ plug-ins/CsvDriver/trunk/build.xml 2020-08-09 17:49:20 UTC (rev 6371)
@@ -16,7 +16,7 @@
-
+
Modified:
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/AutoCSVFile.java
===
--- plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/AutoCSVFile.java
2020-08-05 13:45:55 UTC (rev 6370)
+++ plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/AutoCSVFile.java
2020-08-09 17:49:20 UTC (rev 6371)
@@ -43,15 +43,15 @@
// Pattern to differenciate a comment line Pattern starting with #
// from a header line Pattern starting with #FID or #X (old xyz format)
-private final static Pattern SHARP_PATTERN =
Pattern.compile("^#(?!(FID|X)[\t,;\\| ])");
+private final static Pattern SHARP_PATTERN =
Pattern.compile("^#(?!(FID|X)[\t,;| ])");
// Pattern matching a unquoted, integer, decimal or scientic number
// A non-comment line containing such a pattern is considered as a data
line
-private final static Pattern NUMBER_PATTERN =
Pattern.compile("[\\s\\|,;]-?\\d+(\\.\\d+([eE][-\\+]\\d+)?)?[\\s\\|,;]");
+private final static Pattern NUMBER_PATTERN =
Pattern.compile("[\\s|,;]-?\\d+(\\.\\d+([eE][-+]\\d+)?)?[\\s|,;]");
// Pattern matching a WKT string
// A non-comment line containing such a pattern is considered as a data
line
-private final static Pattern WKT_PATTERN =
Pattern.compile("(((MULTI)?(POINT|LINESTRING|POLYGON))|GEOMETRYCOLLECTION) ?(
EMPTY|\\([\\(\\)\\d,\\. ]*\\))");
+private final static Pattern WKT_PATTERN =
Pattern.compile("(((MULTI)?(POINT|LINESTRING|POLYGON))|GEOMETRYCOLLECTION) ?(
EMPTY|\\([()\\d,. ]*\\))");
/** No parameter constructor for persitence in a project file.*/
@@ -87,9 +87,10 @@
/**
* Test to guess the encoding of a file (taken from
* neoedmund'editor at http://code.google.com/p/neoeedit/)
- * @Deprecated too dangerous, just use the system default, it can be forced
+ * @deprecated too dangerous, just use the system default, it can be forced
* in the command line
*/
+@Deprecated
private String guessEncoding() throws IOException {
// Main multi-bytes encodings
String local_charset = Charset.defaultCharset().name();
@@ -181,7 +182,7 @@
nonComment++;
}
br.close();
-guessFieldSeparator(lines.toArray(new String[lines.size()]));
+guessFieldSeparator(lines.toArray(new String[0]));
setColumns(line1);
setHeaderLine(hasHeaderLine() && !pirol);
setAttributeTypes(line2);
@@ -200,7 +201,7 @@
// if no lines are provided, return the current fieldSeparator
if (lines.length == 0) return false;
FieldSeparator[] separators = new FieldSeparator[]{TABULATION, COMMA,
SEMI_COLUMN, PIPE, WHITESPACE};
-List> counts = new ArrayList>();
+List> counts = new ArrayList<>();
for (int i = 0 ; i < separators.length ; i++) {
Pattern _fieldPattern = separators[i].getFieldPattern();
counts.add(new HashSet());
@@ -246,7 +247,7 @@
protected void setColumns(String line) throws IOException,
CSVFileException {
-if (line != null /*&& getFeatureSchema() == null*/) {
+if (line != null) {
boolean header = !NUMBER_PATTERN.matcher(line).find() &&
!WKT_PATTERN.matcher(line).find();
setHeaderLine(header);
@@ -258,7 +259,7 @@
* Try to guess geometry columns from the column names and create the
* FeatureSchema
*/
-protected void guessGeometryColumns(String line) throws CSVFileException,
IOException {
+protected void guessGeometryColumns(String line) {
String[] columns = getColumns();
if (columns != null && columns.length>0) {
int wkt = -1;
Modified:
plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/d
[JPP-Devel] SVN: [6372] plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv
Revision: 6372 http://sourceforge.net/p/jump-pilot/code/6372 Author: michaudm Date: 2020-08-09 17:53:34 + (Sun, 09 Aug 2020) Log Message: --- delete en i18n file and add hu Added Paths: --- plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_hu.properties Removed Paths: - plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_en.properties Deleted: plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_en.properties === --- plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_en.properties 2020-08-09 17:49:20 UTC (rev 6371) +++ plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_en.properties 2020-08-09 17:53:34 UTC (rev 6372) @@ -1,20 +0,0 @@ -drivers.csv.file-path=File -drivers.csv.encoding=Encoding -drivers.csv.comment-line-pattern=Comment line (regex) -drivers.csv.field-separator=Field separator -drivers.csv.header-line=Header (column names) -drivers.csv.data-type-line=Data types -drivers.csv.wkt=Column containing WKT geometry -drivers.csv.x=Column containing x value -drivers.csv.y=Column containing y value -drivers.csv.z=Column containing z value - -drivers.csv.options=Options -drivers.csv.quoted=Quoted string -drivers.csv.select-attributes=Select attribute -drivers.csv.export-format=Export format - -drivers.csv.driver-not-fully-configured = CSV Driver could not been fully configured -drivers.csv.error-reading = This file could not be read (it may not be a valid CSV file)\: -drivers.csv.no-data-found = No data found in\: - Added: plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_hu.properties === --- plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_hu.properties (rev 0) +++ plug-ins/CsvDriver/trunk/src/fr/michaelm/jump/drivers/csv/csv_hu.properties 2020-08-09 17:53:34 UTC (rev 6372) @@ -0,0 +1,20 @@ +drivers.csv.file-path = F\u00E1jl +drivers.csv.encoding = Karakterk\u00F3dol\u00E1s +drivers.csv.comment-line-pattern = Megjegyz\u00E9s sor (regex) +drivers.csv.field-separator = Mez\u0151elv\u00E1laszt\u00F3 karakter +drivers.csv.header-line = Fejl\u00E9c (Adatmez\u0151, azaz oszlop nevek) +drivers.csv.data-type-line = Adatt\u00EDpus +drivers.csv.wkt = A WKT geometri\u00E1t tartalmaz\u00F3 oszlop +drivers.csv.x = Az 'x' (v\u00EDzszintes) koordin\u00E1t\u00E1t tartalmaz\u00F3 oszlop +drivers.csv.y = Az 'y' (f\u00FCgg\u0151leges) koordin\u00E1t\u00E1t tartalmaz\u00F3 oszlop +drivers.csv.z = Az 'z' (magass\u00E1g) \u00E9rt\u00E9ket tartalmaz\u00F3 oszlop + +drivers.csv.options = Opci\u00F3k +drivers.csv.quoted = Id\u00E9z\u0151jelezett sz\u00F6veg +drivers.csv.select-attributes = Attrib\u00FAtum v\u00E1laszt\u00E1s +drivers.csv.invert-selection = Kijel\u00F6l\u00E9s megford\u00EDt\u00E1sa +drivers.csv.export-format = Kimeneti form\u00E1tum + +drivers.csv.driver-not-fully-configured = A CSV f\u00E1jl kezel\u0151 eszk\u00F6z nincs megfelel\u0151en be\u00E1ll\u00EDtva +drivers.csv.error-reading = A f\u00E1jl nem olvashat\u00F3 (tal\u00E1n nem val\u00F3s CSV f\u00E1jl...?) \: +drivers.csv.no-data-found = Nincs adat a(z) \: f\u00E1jlban. ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] SVN: [6373] core/trunk
Revision: 6373
http://sourceforge.net/p/jump-pilot/code/6373
Author: michaudm
Date: 2020-08-09 17:57:59 + (Sun, 09 Aug 2020)
Log Message:
---
csv driver -> 1.1.0 (#494) + update hu i18n file
Modified Paths:
--
core/trunk/src/language/jump_hu.properties
Added Paths:
---
core/trunk/lib/plus/csv-driver-1.1.0.jar
Removed Paths:
-
core/trunk/lib/plus/csv-driver-1.0.3.jar
Deleted: core/trunk/lib/plus/csv-driver-1.0.3.jar
===
(Binary files differ)
Added: core/trunk/lib/plus/csv-driver-1.1.0.jar
===
(Binary files differ)
Index: core/trunk/lib/plus/csv-driver-1.1.0.jar
===
--- core/trunk/lib/plus/csv-driver-1.1.0.jar2020-08-09 17:53:34 UTC (rev
6372)
+++ core/trunk/lib/plus/csv-driver-1.1.0.jar2020-08-09 17:57:59 UTC (rev
6373)
Property changes on: core/trunk/lib/plus/csv-driver-1.1.0.jar
___
Added: svn:mime-type
## -0,0 +1 ##
+application/octet-stream
\ No newline at end of property
Modified: core/trunk/src/language/jump_hu.properties
===
--- core/trunk/src/language/jump_hu.properties 2020-08-09 17:53:34 UTC (rev
6372)
+++ core/trunk/src/language/jump_hu.properties 2020-08-09 17:57:59 UTC (rev
6373)
@@ -1,5 +1,7 @@
-translator = Istvan Stefan and Zoltan Siki
-last_change_date = 29 Sept 2012
+#https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/src/language/jump_hu.properties
+
+translator = Istvan Stefan, Zolt\u00e1n Siki and J\u00e1nos Tam\u00e1s Kis
+last_change_date = 04 Aug 2020
last_change_reason = new PointLayerFromAttributeTablePlugIn
JUMPConfiguration.about = N\u00e9vjegy...
JUMPConfiguration.fence = Keret
@@ -12,12 +14,12 @@
JUMPWorkbench.version = Verzi\u00f3
JUMPWorkbench.version-locale = Verzi\u00f3
JUMPWorkbench.jump = OpenJUMP
-JUMPWorkbench.status.initialize-datasources = \#T\:
-JUMPWorkbench.status.show-workbench = \#T\:
-com.vividsolutions.jump.io.ShapefileReader.shp-gt-dbf = \#T\:Error reading
shapefile ''{0}'' \:\n\
- \ number of records in shp ({1}) > number of records in dbf ({2}).
-com.vividsolutions.jump.io.ShapefileReader.shp-lt-dbf = \#T\:Error reading
shapefile ''{0}'' \:\n\
- \ number of records in shp ({1}) < number of records in dbf ({2}).
+JUMPWorkbench.status.initialize-datasources = Adatforr\u00E1sok
inicializ\u00E1l\u00E1sa
+JUMPWorkbench.status.show-workbench = Mutatsd a 'workbench'-et
+com.vividsolutions.jump.io.ShapefileReader.shp-gt-dbf = Hiba t\u00F6rt\u00E9nt
a(z) ''{0}'' SHP f\u00E1jl beolvas\u00E1sakor\:\n\
+ \ a rekordok sz\u00E1ma az SHP f\u00E1jlban ({1}) > a rekordok
sz\u00E1ma a DBF f\u00E1jlban ({2}).
+com.vividsolutions.jump.io.ShapefileReader.shp-lt-dbf = Hiba t\u00F6rt\u00E9nt
a(z) ''{0}'' SHP f\u00E1jl beolvas\u00E1sakor\:\n\
+ \ a rekordok sz\u00E1ma az SHP f\u00E1jlban ({1}) > a rekordok
sz\u00E1ma a DBF f\u00E1jlban ({2}).
com.vividsolutions.jump.plugin.edit.NoderPlugIn = Csom\u00f3pont
k\u00e9sz\u00edt\u0151
com.vividsolutions.jump.qa.diff.DiffGeometry.Matching-features = Egyez\u0151
elemek
com.vividsolutions.jump.qa.diff.DiffGeometry.features = elemek
@@ -118,7 +120,7 @@
com.vividsolutions.jump.workbench.ui.plugin.ClearSelectionPlugIn =
Kiejl\u00f6l\u00e9s megsz\u00fcntet\u00e9se
com.vividsolutions.jump.workbench.ui.plugin.CloneWindowPlugIn = Ablak
kl\u00f3noz\u00e1s
com.vividsolutions.jump.workbench.ui.plugin.CombineSelectedFeaturesPlugIn =
Kiv\u00e1lasztott elemek egyes\u00edt\u00e9se
-com.vividsolutions.jump.workbench.ui.plugin.CombineSelectedFeaturesPlugIn.invalid-multipolygon
= \#T\:MultiPolygon was not valid, a GeometryCollection has been returned
+com.vividsolutions.jump.workbench.ui.plugin.CombineSelectedFeaturesPlugIn.invalid-multipolygon
= A MultiPolygon \u00E9rv\u00E9nytelen volt, az eredm\u00E9ny
GeometryCollection lett
com.vividsolutions.jump.workbench.ui.plugin.CopySchemaPlugIn = S\u00e9ma
m\u00e1sol\u00e1s
com.vividsolutions.jump.workbench.ui.plugin.DeleteAllFeaturesPlugIn =
\u00d6sszes elem t\u00f6rl\u00e9se
com.vividsolutions.jump.workbench.ui.plugin.DeleteSelectedItemsPlugIn =
Kiv\u00e1lasztott elemek t\u00f6rl\u00e9se
@@ -175,9 +177,9 @@
com.vividsolutions.jump.workbench.ui.style.BasicStylePanel.error-opening-file
= Hiba a f\u00e1jl megnyit\u00e1sakor\: {0}
com.vividsolutions.jump.workbench.ui.style.ChangeStylesPlugIn = St\u00edlusok
megv\u00e1ltoztat\u00e1sa
com.vividsolutions.jump.workbench.ui.warp.AffineTransformPlugIn = Affin
transzform\u00e1ci\u00f3
-com.vividsolutions.jump.workbench.ui.warp.AffineTransformPlugIn.message1=\#T\:Please
load this image as Sextante Raster to perform a transformation
-com.vividsolutions.jump.workbench.ui.warp.AffineTransformPlug
[JPP-Devel] SVN: [6374] core/trunk/ChangeLog
Revision: 6374 http://sourceforge.net/p/jump-pilot/code/6374 Author: michaudm Date: 2020-08-09 17:59:45 + (Sun, 09 Aug 2020) Log Message: --- update changelog Modified Paths: -- core/trunk/ChangeLog Modified: core/trunk/ChangeLog === --- core/trunk/ChangeLog2020-08-09 17:57:59 UTC (rev 6373) +++ core/trunk/ChangeLog2020-08-09 17:59:45 UTC (rev 6374) @@ -4,6 +4,9 @@ # 3. be concise but convey the change in a way that ordinary users understand #< 80 chars --># +2020-08-09 mmichaud + * #494 : upgrade csv driver to 1.1.0 + hungarian i18n file + 2020-08-05 ede * upgrade apache batik (used for svg rendering) to latest 1.13 ___ 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
Thank you for feedback. I removed csv-driver.en and committed jump.hu and for csv-driver.hu. Should be available in next release (r6374+) I modified a bit the driver so that it can now import a file with .csv extension and including wkt geometries. To make it clear, there are two drivers. - WKT (uppercase) is the original one. It can only load and save pure wkt file without attribute. - The new driver (csv-driver) can save geometry as x,y,z or as wkt along with attributes in a .csv file, but in the other way, it could only read x,y columns from file with csv extension. Files with wkt and attributes was accepted by the wkt loader if they had .wkt extension. Now, wkt loader accepts also .csv extension. It is more symmetric (can read what it wrote). Hope it is more clear. I also cleaned up the code a bit. Please test and report. --- ** [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:** Fri Aug 07, 2020 10:24 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
Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments
Thanks for your detailed answer Ede,Not sure I get everything about the pom's problem, but I agree with all your proposition concerning OpenJUMP evolution.One point which is not clear to me is what exactly will make our code obsolete with new versions of java ? Seems that at the moment, we can write java 8 code and compile it and run it with java 11 or more isn't it ?Michaël envoyé : 9 août 2020 à 17:40de : edgar.sol...@web.deà : jump-pilot-devel@lists.sourceforge.netobjet : [JPP-Devel] OJ 2.x Was:Re: JTS update: first experimentshey Eric,welcome to the team! see my answers belowOn 07.08.2020 20:55, Eric wrote: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 totallyinternally dependent, because otherwise they rely mostly on:http://jump-pilot.sourceforge.net/repository/yeah, that's kind of a backup in case repos disappear which as you correctly determined happened since the last clean up (ages ago;)Even if it is sufficient in a certain extent, I encountered some problems this morning whenI tried to import the Maven dependencies, having a joyful "Failed to transfer [...] Error code429, Too Many Requests". I imagine that some other services are slightly more permissive.planned to move it to the current snapshot build machine at some point, as it holds the latest and most current dependencies of course. but never needed to, so here we are.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.which is the main obstacle. the only clean solution i see is to branch out a new OJ 2.x that initially will break compatibility to all external plugins. that's the bad news.the good news is that this forces us to retouch pretty much all of them and during this effort we might eventually come up with a working plugin manager after all.>This is quite a good news becauseif 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 codeneed to be modified.yeah, probably not. deegree2 is afaics used primarily or exclusively for the WFS extension and i remember checking out deegree3 as a drop in for deegree2 but failing miserably. that's why i stuck with deegree2 happy to have at least a working WFS extension for the time being.but again, we can remove WFS from core for OJ 2.x and come up with a working extension later (if at all).It was therefore time to remove the current OJ JTS dependencies in the Maven configurationand to replace them with: org.locationtech.jts jts-core 1.17.0 org.locationtech.jts jts-io 1.17.0 pomNote that the second dependency has a pom type. Therefore, by default, it didn't importthe jts-io related code, based on the current Maven configuration. This JTS IO pomonly 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.pomIt 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,that corresponds to my findings when trying to find a solution to the package renaming dilemma jts created in 2018. we talked about it on the ml but didn't find a solutionhttps://sourceforge.net/p/jump-pilot/mailman/jump-pilot-devel/thread/CA%2BALWNw%3DBfuQGjNLuOPgxU%2BBz7tcB5FeytomPVqFe9M5Sbh1hQ%40mail.gmail.com/#msg36283823orhttps://sourceforge.net/p/jump-pilot/mailman/search/?q=%22jts+1.15%22&limit=250&page=0&sort=posted_date%20desc- the GeoJSON part (com.vividsolutions.jump.io.geojson) is problematic due to the jts-iopom type only, but once imported, this part of the code will be functional again,how do you figure? com.vividsolutions.jump.io.geojson was written by myself from scratch utilizing google's json-simple . it holds no dependency apart from the jts geometry code. maybe myself placing it in this package has mislead you ;)- some classes have been deprecated, removed, or simply moved in the new JTS versions,such as com.vividsolutions.jts.geom.DefaultCoordinateSequenceFactory. N
Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments
did i write "make our code obsolete with new versions of java"? while i'm not generally opposed to /top posting/, this is exactly what /inline replying/ is for ;) just place your question under the unclear lines in the dialog below and everyone and me understands what you are referring too :) ..ede On 09.08.2020 20:38, Michaud Michael wrote: > Thanks for your detailed answer Ede, > > Not sure I get everything about the pom's problem, but I agree with all your > proposition concerning OpenJUMP evolution. > > One point which is not clear to me is what exactly will make our code > obsolete with new versions of java ? Seems that at the moment, we can write > java 8 code and compile it and run it with java 11 or more isn't it ? > > Michaël > > > >> envoyé : 9 août 2020 à 17:40 >> de : edgar.sol...@web.de >> à : jump-pilot-devel@lists.sourceforge.net >> objet : [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments >> >> >> hey Eric, >> >> welcome to the team! see my answers below >> >> On 07.08.2020 20:55, Eric wrote: >> >>> 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/ >>> >> yeah, that's kind of a backup in case repos disappear which as you correctly >> determined happened since the last clean up (ages ago;) >> >>> 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. >>> >> planned to move it to the current snapshot build machine at some point, as >> it holds the latest and most current dependencies of course. but never >> needed to, so here we are. >> >>> 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. >>> >> which is the main obstacle. the only clean solution i see is to branch out a >> new OJ 2.x that initially will break compatibility to all external plugins. >> that's the bad news. >> the good news is that this forces us to retouch pretty much all of them and >> during this effort we might eventually come up with a working plugin manager >> after all. >> >> >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. >>> >> yeah, probably not. deegree2 is afaics used primarily or exclusively for the >> WFS extension and i remember checking out deegree3 as a drop in for deegree2 >> but failing miserably. that's why i stuck with deegree2 happy to have at >> least a working WFS extension for the time being. >> >> but again, we can remove WFS from core for OJ 2.x and come up with a working >> extension later (if at all). >> >>> 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, >>> >> that corresponds to my findings when trying to find a solution to the >> package renaming dilemma jts cr
