Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

On 28.09.2020 21:46, Rahkonen Jukka (MML) wrote: > Yes, the only robust way to deal with SpatiaLite and GeoPackage geometries > would probably be to use the duck test like our DB Query Plugin does. If the > result is a blob that like a SpatiaLite BLOB or like a GeoPackage BLOB, then > it

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

hey Jukka, looked a bit deeper. sqlite is not really tagging cols retrieved in the metadata apart from known col types (eg. text,blob,...) . it obviously is is totally ignorant of geometries. as a workaround we could "transport" a type information in the col name which is then used in OJ

Re: [JPP-Devel] Run datastore query too tied to schema with Spatialide DS

well, at least spatialite works again :)) yayhh. wrt. the issue below. https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/src/com/vividsolutions/jump/datastore/spatialite/SpatialiteValueConverterFactory.java#l47 is where the column type is "detected" and it uses the column name to do

Re: [JPP-Devel] Spatialite datastore and mod_spatialite

On 27.09.2020 23:27, Michaud Michael wrote: > I saw that in sqlite driver, there are many tests like  > "if(pragmaTable.containsKey(akey))" where pragmaTable comes from the > Properties parameter. Maybe that's this way of using Properties that makes > "defaults" invisible. and yes, sounds

Re: [JPP-Devel] Spatialite datastore and mod_spatialite

hey Jukka, your hunch that the load extension permission was totally on point albeit it was very much hidden. please try r6552. works for me. btw. the proper location for native binaries is lib/native/ or even more specific lib/native/x86/ or lib/native/x64/ depending what platform the

Re: [JPP-Devel] Spatialite datastore and mod_spatialite

as said, identical code wrt. functionality. the permission is needed since a long time and you can find the code in https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/src/com/vividsolutions/jump/datastore/spatialite/SpatialiteDataStoreDriver.java#l73 it's done via reflection but

Re: [JPP-Devel] Spatialite datastore and mod_spatialite

hey Jukka, i can replicate that mod_spatialite (v4 or 5, actually any version) is loaded correctly with DBQuery but not the DataStoreLayer framework. as to why i'm totally stumped as they actually do identical things codewise, wasted the whole friday on this. would you mind adding a bug

Re: [JPP-Devel] 6506 loading raster test

hey Rob, actually it's Edgar but call me ede ;9 anyway, please try snapshot r6526 and come back with results. thx! ..ede On 9/22/2020 23:34, Roberto Rossi wrote: > Hello Edgard, > i repeated the test with the "-v trace" option... the log is really verbose > now: from 50 to 15000 kb! :-) > > I

Re: [JPP-Devel] SVN: [6517] core/trunk/src/com/vividsolutions/jump/workbench/imagery/ geotiff

hey Mike, questions inline On 22.09.2020 16:56, jump-pilot-svn--- via Jump-pilot-devel wrote: > Revision: 6517 > http://sourceforge.net/p/jump-pilot/code/6517 > Author: michaudm > Date: 2020-09-22 14:56:54 + (Tue, 22 Sep 2020) > Log Message: > --- > Do not use

Re: [JPP-Devel] SVN: [6518] core/trunk/src/org/openjump/core/rasterimage

On 22.09.2020 18:20, Giuseppe Aruta wrote: > Hi Ede, > The changes I did: > a) remove the reading of overviews as you suggested why didn't you disable/comment the whole method? > b) removed the usage of commons imaging to compute some metadata > the reason is that those metadata are already

Re: [JPP-Devel] SVN: [6518] core/trunk/src/org/openjump/core/rasterimage

hey Peppe, ajaics this still leaves private static ImageAndMetadata readImage(File tiffFile, int overviewIndex, int indexStart, Point originalSize, Resolution originalCellSize, Envelope wholeImageEnvelope, Envelope viewportEnvelope, double noDataValue, Stats stats) throws

Re: [Duplicity-team] [Question #693039]: Deja dup error

On 22.09.2020 18:00, Erardo Meriño Ibarra wrote: > New question #693039 on Duplicity: > https://answers.launchpad.net/duplicity/+question/693039 > > For several weeks, Deja-Dup has not made backup copies. The following error > appears: > Failed to read >

Re: [JPP-Devel] Fwd: [jira] [Commented] (IMAGING-267) Colorful rendering of b/w Monoband TIF

TIFF image.  Is there some > setting in the application you used that overwrites the settings from the > TIFF file? > > !ISSUE_267.JPG! > > > > > Colorful rendering of b/w Monoband TIF > > -- > > > &

Re: [JPP-Devel] SVN: [6507] core/trunk/src/org/openjump/core/rasterimage

On 22.09.2020 16:18, Giuseppe Aruta wrote: > I prefer to  comment out and build a new clean method up to you. as long as it is not active while we are trying to beat it into shape ;).. ede ___ Jump-pilot-devel mailing list

Re: [JPP-Devel] 6506 loading raster test

hey Roberto, the verbosity setting was just added to the start scripts, so it is not actually documented yet. looks like your on windows. on windows edit 'bin/oj_windows.bat' find rem -- set some default OJ options here (eg. -v debug), initialize empty -- rem -- run OJ with '--help' argument

[JPP-Devel] Fwd: [jira] [Commented] (IMAGING-267) Colorful rendering of b/w Monoband TIF

.JPG! Colorful rendering of b/w Monoband TIF -- Key: IMAGING-267 URL: https://issues.apache.org/jira/browse/IMAGING-267 Project: Commons Imaging Issue Type: Bug Reporter: edgar soldin

Re: [JPP-Devel] SVN: [6507] core/trunk/src/org/openjump/core/rasterimage

On 9/22/2020 13:49, Giuseppe Aruta wrote: +       private static ImageAndMetadata readImage(File tiffFile, int overviewIndex, int indexStart, Point originalSize, +           Resolution originalCellSize, Envelope wholeImageEnvelope, Envelope viewportEnvelope, double noDataValue, +           

Re: [JPP-Devel] SVN: [6513] core/trunk/src/org/openjump/sigle/utilities/geom/ FeatureCollectionUtil.java

Peppe, just rephrased/formatted/typofixed some more. can you check that it describes what is done? ..thx ede On 9/22/2020 13:26, jump-pilot-svn--- via Jump-pilot-devel wrote: Revision: 6513 http://sourceforge.net/p/jump-pilot/code/6513 Author: edso Date: 2020-09-22 11:26:31

Re: [JPP-Devel] SVN: [6508] core/trunk/src/org/openjump/sigle/utilities/geom/ FeatureCollectionUtil.java

any specific reason why you added it to the class in the sigle package? ..ede On 9/22/2020 12:25, Giuseppe Aruta wrote: Done Il giorno mar 22 set 2020 alle ore 12:06 mailto:edgar.sol...@web.de>> ha scritto: Peppe, some comments inline below ..ede On 9/22/2020 11:30, jump-pilot-svn---

Re: [JPP-Devel] SVN: [6507] core/trunk/src/org/openjump/core/rasterimage

we already have support for reading GeoReferencedRaster.parseGDALMetaData(URI uri) (seems format agnostic too). but that is depending on GDAL installed, while the implementaion in TiffUtils.calculateStats() seems be plain java utilizing some apache commons imaging code but is limited to TIFF

[jira] [Commented] (IMAGING-267) Colorful rendering of b/w Monoband TIF

[ https://issues.apache.org/jira/browse/IMAGING-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17199981#comment-17199981 ] edgar soldin commented on IMAGING-267: -- is there a way to answer per mail but retaining the quotes

[jira] [Updated] (IMAGING-267) Colorful rendering of b/w Monoband TIF

[ https://issues.apache.org/jira/browse/IMAGING-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edgar soldin updated IMAGING-267: - Attachment: mdt25a.tif.aux.xml mdt25a.tfw i attached the accompanying world

Re: [JPP-Devel] SVN: [6508] core/trunk/src/org/openjump/sigle/utilities/geom/ FeatureCollectionUtil.java

Peppe, some comments inline below ..ede On 9/22/2020 11:30, jump-pilot-svn--- via Jump-pilot-devel wrote: Revision: 6508 http://sourceforge.net/p/jump-pilot/code/6508 Author: ma15569 Date: 2020-09-22 09:30:06 + (Tue, 22 Sep 2020) Log Message: --- added two method to

Re: [JPP-Devel] SVN: [6507] core/trunk/src/org/openjump/core/rasterimage

hey Peppe, nice try, but no dice. the reason i created an explicit TiffUtilsV2 was to make sure it contains no reference to RasterImageIO or TiffTags anymore. the idea is to wrap GeoReferencedRaster functionality to reuse. GeoReferencedRaster includes all functionality for retrieving an Envelope

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

On 21.09.2020 17:19, Giuseppe Aruta wrote: > Hi Ede, > it works fine. I was able to cut a selected part of the image. And also I > tested on some simple  tools form Sextante that generate raster (Rasterize a > vector layer, change no data value..). > Let us wait for Roberto's test. I think that

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

the "colors" look a little bit wrong though. different form the original image.. ede On 9/21/2020 16:02, ede wrote: Peppe, please try r6506. extracting a part works for me now. tested on Ubuntu 20. ..ede On 9/21/2020 11:03, Giuseppe Aruta wrote: OK. *First test* a) downloaded 6504 b)

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

thanks, will investigate.. ede On 9/21/2020 13:56, Giuseppe Aruta wrote: On the toolbar. The one that looks like a gray box image.png Il giorno lun 21 set 2020 alle ore 13:47 > ha scritto: On 9/21/2020 11:03, Giuseppe Aruta wrote: > h) I drew a fence on

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

On 9/21/2020 11:03, Giuseppe Aruta wrote: h) I drew a fence on the raster g) On layer tree, selecting Depit070.tif, I clicked on tool "Extract selected part of the image" where can i find the tool to draw a fence? ..ede ___ Jump-pilot-devel

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

On 21.09.2020 10:20, Giuseppe Aruta wrote: >>home/giuseppe/Desktop/GIS/OpenJUMP/OpenJUMP-20200915-r6484-PLUS is too old. >>1. please make sure that you use the latest snapshot r6504 > > That is only the folder where I save the OpenJUMP.jar file compiled  from > SVN. I should change the name, your

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

/home/giuseppe/Desktop/GIS/OpenJUMP/OpenJUMP-20200915-r6484-PLUS is too old. 1. please make sure that you use the latest snapshot r6504 2. enable debugging as explained earlier '-v debug' 3. disable the RasterImageIO patch beforehand. it should not be needed. repeat your tests and send the

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

On 20.09.2020 18:53, Giuseppe Aruta wrote: > :-) > Sorry for misunderstanding. nuhhh. no problemo. > Roberto starts the course at the 1 of October.  > He can use OJ 1.15, as well: apart from framework to read raster, there are > no so many changes in raster tool, except the new pixel inspector

Re: [JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

Peppe, misunderstanding ;). my question is when do you need it working as stable or better as in OJ 1.15? when do the courses start? ..ede On 20.09.2020 18:19, Giuseppe Aruta wrote: > Hi Ede >>what was your time frame again? > TiffUtils ->6398  30/08/2020 > RasterImageLayer  -> 6399  

[JPP-Devel] apache commons imaging vs. monoband tiffs

fyi, just opened an issue wrt. to a monoband raster provided by Peppe https://issues.apache.org/jira/browse/IMAGING-267 ..ede ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net

[jira] [Updated] (IMAGING-267) Colorful rendering of b/w Monoband TIF

[ https://issues.apache.org/jira/browse/IMAGING-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edgar soldin updated IMAGING-267: - Summary: Colorful rendering of b/w Monoband TIF (was: Colorful renderig of b/w Monoband TIF

[jira] [Created] (IMAGING-267) Colorful renderig of b/w Monoband TIF

edgar soldin created IMAGING-267: Summary: Colorful renderig of b/w Monoband TIF Key: IMAGING-267 URL: https://issues.apache.org/jira/browse/IMAGING-267 Project: Commons Imaging Issue Type

[JPP-Devel] Fwd: [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

Mike, Jukka, as you are far more knowledgeable wrt. to file formats you maybe want to come up with some tiled TIFFs or otherwise difficult formats that are currently not readable by Apache Commons Imaging as requested below?! tickets can be opened (after a short account creation) on

Re: [JPP-Devel] [jump-pilot:bugs] Re: #498 Most GeoTIFF drivers fail with a simple GeoTIFF image

On 19.09.2020 07:56, Giuseppe Aruta wrote: > Ede, MIchael, > regarding RasterImageLayers. > At this stage, even if I partially solved the problems of the warning from my > side, Roberto still finds them. > I also find a problem on Sextante. Whenever a raster is generated by a > Sextante tool, it

[jira] [Commented] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF

[ https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17198959#comment-17198959 ] edgar soldin commented on IMAGING-265: -- >>The problematic image uses Planar Configura

Re: [PATCH 2/4] base-files/functions.sh: do not iterate over ls

On 20.09.2020 07:31, Rosen Penev wrote: > - for file in $(ls $1/*.sh 2>/dev/null); do > - . $file > + for file in "$1"/*.sh; do > + [ -e "$file" ] || break > + . "$file" the existence check is probably meant to catch "../*.sh" entry found if no files

Re: [JPP-Devel] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

let me have a look at it over the weekend. i am fairly certain that i can cut out some computing which is not necessary for sextante raster, which might already fix this issue. ..ede On 9/17/2020 15:34, Giuseppe Aruta wrote: > In any case I need compare the same errors with Roberto: > we are

Re: [JPP-Devel] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

hey Peppe, On 9/17/2020 14:58, Giuseppe Aruta wrote: > Hi Ede, > the class > com.vividsolutions.jump.workbench.imagery.geoimg.GeoReferencedRaster (and > related) work very well on loading raster in sextante. > In order to clean up from any message error belonging to classes non used > by

[JPP-Devel] Fwd: [jira] [Commented] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF

rmat: TIFF >Affects Versions: 1.0-alpha2 >Reporter: edgar soldin >Priority: Major > Attachments: small_world.tif, small_world_split.jpg > > > hi, >   > we on the OpenJUMP project cannot open some GeoTIFFs with commons.imaging . > for details y

Re: [JPP-Devel] SVN: [6490] core/trunk/src/com/vividsolutions/jump/workbench/ui/ JTablePanel.java

Peppe, apart from the typo it is as well cluttering our API. let's find a cleaner way to achieve what you want! ..ede On 9/17/2020 6:32, jump-pilot-svn--- via Jump-pilot-devel wrote: > Revision: 6490 > http://sourceforge.net/p/jump-pilot/code/6490 > Author: ma15569 > Date:

Re: [JPP-Devel] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

hey Peppe, could you provide one or more of the problematic image files as well? ..ede On 9/16/2020 7:12, Giuseppe Aruta wrote: > Hi Ede, > I also attached to this mail a more exhaustive error message. > > This is what the console shows sometimes when the error occurs in OpenJUMP. > This

Re: [JPP-Devel] Error message on Monoband raster loaded as ReferencedImage or as RasterImageLayer

Peppe, please provide the complete error stacks or even better the OJ log file ..ede On 9/15/2020 13:14, Giuseppe Aruta wrote: > Hi all > Sometimes I try to load a monoband raster, like the one I attached to this > mail, and I get this message of error: > >  /(Referenced Image Exception) >

Re: [JPP-Devel] [jump-pilot:bugs] #503 1/2 pixel shift in image georeferencement

no problemo. maybe you shouldn't test readers as such but ways of georeferencing? meaning worldfile, gdal & geotiff parsing. probably easiest if you simply temporarily comment/uncomment those in GeoReferencedRaster.. ede On 9/14/2020 23:17, michael michaud via Jump-pilot-devel wrote: > Thanks

Re: [JPP-Devel] SVN: [6461] core/trunk/src/org/openjump/core/rasterimage

Peppe, i noticed earlier that your image reading implementation creates a new Reader on every render call but thought you will notice when this becomes a performance issue. seeing you continue this trend with code like below i become a little worried ;) and suggest you try to model your

Re: [JPP-Devel] SVN: [6432] core/trunk/src/org/openjump/core/rasterimage/ RasterImageIO.java

Peppe, this does not compile on my side. are there changes missing? ..ede Description ResourcePathLocationType band cannot be resolved to a variable RasterImageIO.java /proj_oj-core/src/org/openjump/core/rasterimage line 387Java Problem col cannot be

[jira] [Updated] (IMAGING-265) ArrayIndexOutOfBoundsException on reading simple GeoTIFF

[ https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edgar soldin updated IMAGING-265: - Summary: ArrayIndexOutOfBoundsException on reading simple GeoTIFF

[jira] [Created] (IMAGING-265) ArrayIndexOutOfBoundsException on reading TIFF

edgar soldin created IMAGING-265: Summary: ArrayIndexOutOfBoundsException on reading TIFF Key: IMAGING-265 URL: https://issues.apache.org/jira/browse/IMAGING-265 Project: Commons Imaging

Re: [JPP-Devel] How to use com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster

On 03.09.2020 09:33, Giuseppe Aruta wrote: > Hi Ede,is it possible to use > com.vividsolutions.jump.workbench.imagery.geoimg.GeoRaster > to read an image file? > And how? same as GeoReferencedRaster but as public class GeoReferencedRaster extends GeoRaster you don't really gain anything,

Re: [JPP-Devel] wms layer title

On 03.09.2020 19:59, Michaud Michael wrote: > Thank you for this clear description Jukka, > > I will follow Ede's suggestion to log a warning if a (mandatory) title is how about logging it as error. as it seems to be one but will only be logged and hence not obstruct the users experience. >

Re: [JPP-Devel] wms layer title

i see. right. that happens when you don't have a proper test dataset :). we should maybe also log a warning as an empty title is irregular as i understand. is it not? ..ede On 9/2/2020 14:55, Michaud Michael wrote: > Did you change null title of layer elements ? > > Seems that the getTitle you

Re: [JPP-Devel] wms layer title

On 9/2/2020 14:02, Michaud Michael wrote: > Hi Ede, > > One problem with wms title was with "Layer" title = null. Ticket is ambiguous > because the exception is thrown during getCapabilities which also have a > title. > > Just tried a new fix. Will let you know soon. why? title was set to an

Re: [JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

thx Peppe, as long as it didn't get worse all is fine.. ede On 01.09.2020 18:05, Giuseppe Aruta via Jump-pilot-devel wrote: > Export is fine for Vector and ReferenceImageLayer at any scale. > > Export RasterImageLayer: it is rescales and sometimes lost if we rescale the > view using saving

[JPP-Devel] Fwd: SVN: [6400] core/trunk/src/com/vividsolutions/jump/workbench/ui/ WorkbenchFrame.java

can't test within eclipse. will have to run it in a vm. please test as well. ..ede Forwarded Message Subject: [JPP-Devel] SVN: [6400] core/trunk/src/com/vividsolutions/jump/workbench/ui/ WorkbenchFrame.java Date: Mon, 31 Aug 2020 12:02:20 + From: jump-pilot-svn--- via

Re: [JPP-Devel] [jump-pilot:bugs] #500 possible important bug on Batik 1.6.1

On 31.08.2020 07:19, Giuseppe Aruta via Jump-pilot-devel wrote: > I remember we downgrade from Batik 1.13 to Batik 1.6.1 because of problems to > export to SVG one of the reasons apart from the stack that i don't believe it's batik. there's no svg involved here. 1. is "Extract selected part"

Re: [JPP-Devel] [jump-pilot:bugs] #499 SelectFilesOptionPanel and extensions

On 30.08.2020 22:19, michael michaud via Jump-pilot-devel wrote: > Ede, > The I18NPlug class I use in csv may not be the best way to internationalize > csv extension, but the problem is not there. > > I'll try to give a more complete description : > In OpenJUMP, SelectFilesOptionPanel

Re: [JPP-Devel] SVN: [6391] core/trunk/src/org/openjump/core/ui/plugin/raster/ RasterImageLayerPropertiesPlugIn.java

so tl;dr tested and approved :).. thanks just wanted to make sure. wrt to your detailed post below, yeah ReferencedImage is basically just that, a reference to the image where all transformations applied in real time by the render chain via JAI on each display attempt thus minimizing the

Re: [JPP-Devel] [jump-pilot:bugs] #483 RasterStyleDialog freezes if the selected raster has only one value (raster used as mask)

Peppe, please reply on sf.net and close/tag the tickets appropriately usually there is a link in the message like >> * [bugs:#483] ..ede On 29.08.2020 10:43, Giuseppe Aruta wrote: > Yes. It Is solved in my tests. No feedback from whom pointed out

Re: [JPP-Devel] [jump-pilot:bugs] #480 SLD import/export problems

thx Mike, just posted about the milestones again, but see it was understood already :).. ede On 29.08.2020 10:47, michael michaud wrote: > Peppe, do we tag that as OJ_Future ? > > > --- > > ** [bugs:#480] SLD import/export problems** > > **Status:** open > **Milestone:** > **Created:** Sun Dec

[JPP-Devel] milestones & bug tracker

hey All, i added milestones OJ_future (not urgent, somewhen in the future) OJ_2.x (in the next major release, eg. because depending on JTS 1.15+) OJ_1.16 (important or easy bugs, where fixes shoud go into last OJ 1.x release) to the sf.net bug tracker, so we can assign bugs to them. please do

Re: [JPP-Devel] SVN: [6391] core/trunk/src/org/openjump/core/ui/plugin/raster/ RasterImageLayerPropertiesPlugIn.java

hey Peppe, hmm these changes create a copy of the image in memory. can you check with a really big file that this does not "explode" in memory? ..ede On 8/27/2020 10:07 AM, jump-pilot-svn--- via Jump-pilot-devel wrote: > Revision: 6391 > http://sourceforge.net/p/jump-pilot/code/6391 >

Re: [JPP-Devel] SVN: [6393] core/trunk

hey Nico, something went wrong with the language files as well. my guess is that your IDE converted them to unicode. the OJ svn is unfortunately still ISO-8859-1 encoded. i'll revert the changes and keep com.vividsolutions.jump.datastore.spatialite.SpatialiteDataStoreDriver.file-does-not-exist

Re: [JPP-Devel] SVN: [6393] core/trunk

he's alive :) hey Nico, when logging errors using Logger.error() i'd suggest logging the Throwable itself so the stack is not lost. if you want to add a message you can do that as well eg. Logger.error('my message',e) there are some minor spelling mistakes as well. i'll tackle those and add

[JPP-Devel] java.io.EOFException when saving SHP files

hey Mike and All, i am still getting those. do they happen to anyone else? what i do is: 1. open attached JML file 2. save as SHP using 'Save as'/'Save as (testing)' with a new file name. 8 times out of 10 the error occurs ..ede [ERROR] 16:48:46.250 java.io.EOFException java.io.EOFException

Re: [JPP-Devel] Offset in the digitizing tools

Jukka, could you give more details? OS, Version, Display Resolution? by any chance 4k? ..ede ps. did you receive my mails about the OGC API? On 8/26/2020 12:36 PM, Rahkonen Jukka (MML) wrote: > I noticed that I have this issue only with one computer but unfortunately I > use that one for

Re: [JPP-Devel] SVN: [6387] core/trunk/src/org/openjump/core/rasterimage/ RasterImageLayer.java

On 8/26/2020 12:06 PM, Giuseppe Aruta wrote: > Hi Ede > I copied/pasted from a local file in Eclipse. In other situations it didn't > replace the whole file. a good approach to prevent that is to check the commit by doubleclicking the changed file in the commit dialog. it opens a compare view,

Re: [JPP-Devel] SVN: [6387] core/trunk/src/org/openjump/core/rasterimage/ RasterImageLayer.java

hey Peppe, quite a chunk? seems like you refomatted the whole file (again) ;( looks like you replaced the JAI operations, which seems to be no biggie as they are rendered into RAM anyway 'img.getAsBufferedImage()'. we have other places where JAI is still used and the advantage is that a chain

Re: [JPP-Devel] sqlite database

On 8/24/2020 1:23 PM, Michaud Michael wrote: > Just to precise what I fixed wrt. to what Ede is suggesting : > > I could not read spatialite files from QGis because GeometryColumn.isIndexed() > returned null for some GeometryColumnsLayouts. > > I fixed it for OGC_OGR_LAYOUT (used by QGIS when

Re: [JPP-Devel] sqlite database

you can simulate it, simply return NULL in SpatialiteDSMetadata.getGeometryColumn(String datasetName, String geoCol) for testing and you should end up with the stack. wrt. what Mike did. he wrote earlier On 8/22/2020 11:18 AM, Michaud Michael wrote: > > Finally got it : there was a bug

Re: [JPP-Devel] sqlite database

On 23.08.2020 20:25, Michaud Michael wrote: > Ede, > > Broken tests : my feeling is that FlexibleDateParser is doing too much (more > than hundred different formats). surely is. my point merely is that if testing, as in the test case June 1970 June 19 than the order dd is

Re: [JPP-Devel] sqlite database

hey Nico, On 21.08.2020 10:52, Michaud Michael wrote: >> >> 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 >> >> >>

Re: [JPP-Devel] sqlite database

On 22.08.2020 22:24, Michaud Michael wrote: > I reactivated the code parsing Date attributes as dates during data loading. > The > slowdown observed during saving should be moved to loading, but thanks to > Ede's > fix, FlexibleDateParser is now much more efficient (exploration to find the >

Re: [JPP-Devel] sqlite database

On 21.08.2020 10:52, Michaud Michael wrote: > Sorry, I think my test base was empty or something like that hehe, yeah the feeling you get after you spend hours fixing something and wonder why it still does not work that you are are editing the wrong repo/code path, that you were dead sure was

Re: [JPP-Devel] sqlite database

Nico, maybe Mike can provide you the sqlite file he created to test against?.. ede On 21.08.2020 10:25, Nicolas Ribot wrote: > Hi, > > It was supposed to work. > I will have a look > > Nicolas > > On Thu, 20 Aug 2020 at 20:24, Michaud Michael > wrote: > >> Hi Jukka, Nicolas >> >> Do you know

Re: [JPP-Devel] OpenJUMP migration documentation

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

Re: [JPP-Devel] Offset in the digitizing tools

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

Re: [JPP-Devel] batik upgraded

iText ;) https://sourceforge.net/p/jump-pilot/code/HEAD/tree/plug-ins/SkyPrinterPlugIn/src/main/java/com/isa/jump/plugin/PDFDriver.java#l3 ..ede On 17.08.2020 10:21, Rahkonen Jukka (MML) wrote: > Hi, > > I wonder what library the SkyJUMP printer plugin is using for PDF export. > > -Jukka

Re: [JPP-Devel] batik upgraded

done in r6375. to batik 1.6.1 instead of 1.6 though. would you mind doublechecking that it works as expected again? ..ede On 16.08.2020 16:01, Giuseppe Aruta wrote: > I suggest to move back to Batik 1.6 and to keep the option to move either > to smaller SVG lib or a newer Batik for OpenJUMP

Re: [JPP-Devel] batik upgraded

On 16.08.2020 13:07, Giuseppe Aruta wrote: > Hi all, > this issue was not closed: moving to newer batik broke SVG export for both > embedded OpeJUMP "Export view" and CadPlan Printer view plugin. yeah, didn't hear back from you guys. so we are agreed thta i'll roll back the upgrade to the latest

Re: [JPP-Devel] Git migration

On 15.08.2020 12:07, Eric wrote: > Hi all, > > After 5-6 hours, the result of the migration is finally complete: > https://github.com/openjump-gis/openjump-migration > > It includes the commit history from revision 859 to 6242. just checked, we'll lose some commits to the source this way. did

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

some more questions 1. did it ever run through completely? 2. why start at revision 859? 3. did you try https://github.com/nirvdrum/svn2git#debugging ? it'd probably more stable if you could work with a full local checkout.. ede On 14.08.2020 21:26, Eric wrote: > The command is to migrate the

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

probably just sf.net's svn acting up. it sometimes throws weird errors that resolve itself after a time. i guess they get fixed on their servers. who knows. anyway. what is it you are doing when it errs out? a complete checkout? what commands are you running? can you give some context? ..ede

Re: [JPP-Devel] You've been made an owner of the OpeenJUMP organization

just added minor clarification to the repo title. apart from that go ahead :) and don't forget to drink plenty if you are on this planets summer side ;) On 14.08.2020 12:44, Eric wrote: > I saw that too. It has already been corrected. Logo and URL added as well. > > And I don't know why you

Re: [JPP-Devel] You've been made an owner of the OpeenJUMP organization

Eric, any idea where the 'OpeenJUMP' note the double e stems from? ..ede On 14.08.2020 12:29, OpeenJUMP wrote: > You have been granted admin access to OpeenJUMP. Admins have full rights to > the organization and have complete access to all repositories and teams. > > View all OpeenJUMP admins:

Re: [JPP-Devel] [GitHub] @ericgrosso has invited you to join the @openjump-gis organization

Eric, thanks. as stated, for the time being it's as good as any other name. if someone objects that might change but my bet is you just settled it on the first try :) ..ede On 14.08.2020 12:18, Eric wrote: > As I previously wrote, I just created it for the time being based on the >

Re: [JPP-Devel] [GitHub] @ericgrosso has invited you to join the @openjump-gis organization

well then https://github.com/openjump-gis it is. i can live with that.. ede On 14.08.2020 11:27, GitHub wrote: > Hi edeso, > > > > @ericgrosso has invited you to join the @openjump-gis organization on GitHub. > Head over to https://github.com/openjump-gis to check out @openjump-gis’s >

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

oj-devs oj-developers oj-team or jump instead of oj so many possibilieits ..ede:)) On 14.08.2020 11:53, Giuseppe Aruta wrote: > jump-pilot > or > openjump-pilot > or > openjump2 > > 2020-08-14 11:50 GMT+02:00, Eric : >> Hi, >> >> The GitHub support team answered me this morning, stating that the

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

no worries. i'm pretty sure we are not fixed on that name. for years we have been known as /jump-pilot/ (anybody know why?) and it worked as well. how about you work with a private repo in the mean time and we'll deal with name and organisation when we are ready to branch which is not going to

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

yup indenting is clearly broken in this reply, maybe better not reply inline with that client Mike ;).. ede On 12.08.2020 09:17, Michaud Michael wrote: > Hi, > > >>> On 07.08.2020 20:55, Eric wrote: > Then I checked which OJ lib dependencies rely on JTS and it seems that > there is only

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

Jody, understood. thanks for clearing that up! what's the advantage of the EPL2 then if you are essentially also licensed BSD-style? or asked differently why would anyone use the EPL when you can license the product without any restriction whatsoever as well? ..ede On 11.08.2020 16:06, Jody

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

looks like the geoserver folks added an exception for EPL and others to their GPL2. https://docs.geoserver.org/stable/en/user/introduction/license.html unfortunately we cannot relicense our sources as we cannot get the ok from _all_ developers/companies having laid hands on it over time. but

Re: [JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

Eric, sounds plausible. Jody. maybe you can add GPL'd software as another example in https://github.com/locationtech/jts/blob/master/FAQ-LICENSING.md ? thanks.. ede On 11.08.2020 12:58, Eric wrote: > Hi again, > > "The Eclipse Distribution License is an OSI Approved Open Source License by >

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

tl;dr let's wait how the licensing issue (other email) turns out, apart from that my answers below. On 10.08.2020 15:42, Eric wrote: > Hi Ede, > > Thanks for your welcome and for your answers. See my inline replies for some > of them (I deleted the other parts). > > On 09/08/2020 16:40,

[JPP-Devel] Licensing GPL2'd OJ vs. EPL2'd locationtech JTS

hey All, just noticed that locationtech relicensed JTS to EPL2, which as far as i read it is incompatible to the GPL (any version). https://www.eclipse.org/legal/epl-2.0/faq.php#h.mz8pxljvc07w the mentioned "Exhibit A — Form of Secondary Licenses Notice" seems to be empty in JTS' version of

Re: [JPP-Devel] Git Repo ids Was:Re: OJ 2.x Was:Re: JTS update: first experiments

Eric, surely we can use whatever we decide as "email" as long as it fit's the syntax or? as all of these are sf.net users we could simply use the @users.sourceforge.net . ..ede On 11.08.2020 11:50, Eric wrote: > The problem is that email addresses are required to be able to keep the >

[JPP-Devel] Git Repo ids Was:Re: OJ 2.x Was:Re: JTS update: first experiments

working mail addresses will be difficult to get for everyine and generally unnecessary as well. just need to keep the history and committer ids to enable retracing changes in the future as well. ..ede On 10.08.2020 15:52, Eric wrote: > Here is the list of all the SVN authors (and their number

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

looks unmaintained with last commit being from 2017-05-24 https://sourceforge.net/p/gvsigce/code/HEAD/tree/trunk/sextante/ ..ede On 11.08.2020 08:31, Giuseppe Aruta wrote: > Hi Eric > > - This is the link to GvSIG CE SVN of Sextante: > https://svn.code.sf.net/p/gvsigce/code/trunk/sextante > > -

Re: [JPP-Devel] OJ 2.x Was:Re: JTS update: first experiments

hey Mike, On 10.08.2020 09:16, Michaud Michael wrote: > Ede, > >>> 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

<    1   2   3   4   5   6   7   8   9   10   >