hey Jukka, Mike,
as i recall initially a base was used as given and only the generated
parameters (request etc.) were appended. did we run into issues that we limited
the usage of url params in the base url? if not let's just suppose the users
know's what they do and not over-engineer this.
just switched the changelog/readme.txt presented on the bottom of
https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
to a generated one from the git log.
in case you want to check what changed in a snapshot quickly you can read up in
there :).. ede
hey Jukka,
On 25.05.2021 10:32, Rahkonen Jukka (MML) wrote:
> Could not initialize class javax.imageio.ImageIO
please use the latest snapshot r4900(1668fa2).. ede
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
hey Pepe,
On 24.05.2021 15:04, Giuseppe Aruta wrote:
SNIP
> First of all, I discovered that jai_codec-1.1.3.jar and jai_core-1.1.3.jar
> files are missing in both Core and Plus version OpenJUMP-20210523-r4895
> distros. I had to move a copy of this two files from a previous version of
> OJ
thanks for the answer Mike,
seeing that we currently have no up to date documentation on how to develop
extensions and lacking a proper user usable plugin manager, i'd rather have it
in CORE for now. alternatively we might ask them, as it is very small to simply
add it to their jdbc jar?
hey Mike,
just saw your answer to the github ticket and noticed that i didn't voice my
concerns about an extension so far. well one concern, maintainability. while i
notice your concerns about closed source systems and at least for now exotic
systems i don#t think that the little code provided
while adding a generated Changelog text file to the pom i came across the
following link, which explains a bit how a git log comment is structured.
https://chris.beams.io/posts/git-commit/
especially having a separated subject line and keeping the lines under 72chars
seems important to me..
On 17.05.2021 22:46, Michaud Michael wrote:
> Hi,
>
> Thank you for your efforts on maven.
no problemo
> Any improvement to automatize build process is welcome. Just two points of
> attention :
>
> - if I understand correctly, it will also need to revisit every extension
> pom. Just let try to
congrats Jukka,
to your first (hopefully of many) git pull request(s) merged :).. ede
Forwarded Message
Subject: [JPP-Devel] [openjump-gis/openjump] 74c2c9: Add download link for
OpenJUMP 2 snapshots
Date: Mon, 17 May 2021 12:35:24 -0700
From: Jukka Rahkonen via
hey All,
as you might have noticed i am still finetuning the OJ2 maven build. just a
quick status update.
by now the whole build and packaging should be mavenized. while i still didn't
try i'm quite positive that we can get rid of the redundant jars under lib/.
next thing i want to tackle is
On 16.05.2021 12:29, Michaud Michael wrote:
> I don't think it is very important. Just wanted to know if you noticed it,
> and if you choose to let it as is, or if it's just not possible to add an
> offset to the rev number so that v2 > v1.
indeed i did, but i actually don't care as it is
just because i just noticed it,
lib/ contains the files
cts-extension-1.0.0.jar
cts-1.5.2.jar
which seem to belong to the CTS extension by Michael.
while it works for legacy reasons, lib/ is not meant to hold external extension
jars. they should be placed in lib/ext/ for CORE and lib/plus/
hey Mike,
could you please coment on the below? ..ede
Forwarded Message
Subject: Jython JAR size
Date: Tue, 16 Mar 2021 18:10:59 +0100
From: edgar.sol...@web.de
hey All,
just noticed that the current jython-2.7.2.jar is 32MB large as opposed to the
earlier jython-2.2.jar
this
https://github.com/openjump-gis/openjump/runs/2519947298?check_suite_focus=true
stumped me a bit, because it didn't seemed to be related to my changes at all.
as this
https://stackoverflow.com/questions/67001968/how-to-disable-maven-blocking-external-http-repositores
suggests, it
just found this interesting stack answer
https://stackoverflow.com/questions/18216991/create-a-tag-in-a-github-repository
sunny regards.. ede
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
hey Mike,
your latest git pushs contain one
"Merge remote-tracking branch 'origin/main' into main" -
https://github.com/openjump-gis/openjump/commit/1ad74195a6321131f3fb36c16b1ac907e24cad4f
which is just your local replay of a previous commit of mine, the actual
synching.
this needlessly
On 30.04.2021 09:18, Michaud Michael wrote:
> Hi all,
>
> It is nice to already have such a contribution. On the other hand, such a
> plugin will only be used by users having a ocient database which is a big
> proprietary system. From my point of view, an extension in a separate jar
> would be
On 30.04.2021 09:23, Michaud Michael wrote:
> Thanks Ede,
hey Mike,
> Maven build is still a bit mysterious for me. There is something in
> particular that you may be abble to explain to me. I have plenty of warnings
> on properties used in the pom and that seem to be defined nowhere :
>
hey Jukka and All,
we've got our first pull request on github ('huzzah' :) and i just wanna ask if
someone knows about their background and has an opinion about merging support
into OJ Core.
have fun.. ede
ps. :) - https://dilbert.com/strip/2021-04-25
On 29.04.2021 19:50, Michaud Michael wrote:
> Absolutely not,
>
> Sorry for the noise, I wonder how I could test the extension without noticing
> that.
sure, just build/run it with a java8 during development ;)
> Seems that jgrapht switched to java 11 after version 1.4.
>
> I will downgrade the
good news,
just today had time to fix the naming issues of the OJ2 snapshot builds. seems
to be working now. find them on
https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
.
file names contain build datestamp, git revision count and revision id. i
decided to keep the count
hey Mike,
did we raise requirements above java8 already? see below.. ede
[ERROR] 2021-04-29_16:29:00.498 org/jgrapht/graph/Pseudograph has been compiled
by a more recent version of the Java Runtime (class file version 55.0), this
version of the Java Runtime only recognizes class file versions
hey Jason,
packaging is not properly adjusted (yet) for the git repo. please be patient. i
am just working on a fix for the snapshots. keep an eye on the commits and when
it is up use 'mvn package -P snapshot' to package snapshot builds.
..ede
On 27.04.2021 15:14, Jason Arnold wrote:
>
Peppe,
i tend to not touch existing implementations of deprecated API unless the
actual need arises because they got removed. they are proven working and
usually there is enough other urgent stuff to do :)
..sunny greetings ede
On 29.04.2021 07:01, Giuseppe Aruta wrote:
> there are still some
hi Jason,
see my answers inline.
On 18.04.2021 18:15, Jason Arnold wrote:
> Hi all,
>
> My name is Jason Arnold. I'm an architect at a startup company called Ocient
> that has built a distributed relational database for large scale analytics.
> We recently added GIS support to our database,
hey Mike,
it's a combination of reasons,
(1) developing without using mvn builds (we may discourage that in the future)
(2) actually using some of the jars to actually pack the distros via mvn
i agree that having the binaries in the development tree clutters it and blows
up size considerably,
hey Peppe,
there are WIP (work-in-progress) snapshot builds that you can try out
https://sourceforge.net/projects/jump-pilot/files/OpenJUMP2_snapshots/
.
they should work in general. base folder naming in zip is still wrong, but i'll
fix that soonish.. ede
On 08.04.2021 20:06,
hey Mike,
i see you are creating all these repos on github. i'd rather have the repos
created only when there is a at least minimally ported working version of the
extension in them. this way we and others would have a better overview.
what's your rationale for creating them at this time?
On 3/17/2021 13:43, edgar.sol...@web.de wrote:
> if you or actually anyone else realizes a it in any another way, even on
> github, so be it.
still don't think it is a good idea though. Github being closed source n such.
but if it works, it works. priorities! :).. ede
hey Mike,
indeed it is not. it's just a machine permanently connected to the net, that is
payed by me and used for other projects as well. i could give you personal sftp
access if you want to have a look, but otherwise i'd rather not opening it up
for security reasons.
btw. preliminary
hey All,
just noticed that the current jython-2.7.2.jar is 32MB large as opposed to the
earlier jython-2.2.jar with only 1.2MB. looks like there is a slim Jython JAR
wit "only" 14.4MB https://mvnrepository.com/artifact/org.python/jython-slim .
maybe we can include that instead.
didn't check
On 3/15/2021 9:27, Michaud Michael wrote:
> Hi Ede,
hey Mike,
>
> The only automated build which has been set up for now is in
> .github/workflows. It is a direct adaptation of github workflow documentation
> and does the bare minimum : automatically compile the project after each push.
>
> It
hey All,
did anybody already made headway with a working automated maven build from the
github/main branch? if not i would suggest to do it as it is currently done on
a server of mine and pushing the builds on sf.net files. advantages include
1. backupable git repo copy (who knows;)
2.
hey Mike,
made a pull request from your branch to discuss the changeset there
https://github.com/openjump-gis/openjump/pull/3
let's try to establish a workflow. ..ede
On 13.03.2021 19:15, Michaud Michael wrote:
>
> Hi Ede, Peppe,
>
> I committed a rather big change in
hey Peppe,
the official repo is now
https://github.com/openjump-gis/openjump
make sure you got 'Eclipse EGit' installed. then you just need to clone the
above url. enable the branches you are interested in, at least *main* and it
should work. does for me.
also All,
git workflow's main
On 14.02.2021 12:09, Michaud Michael wrote:
> Hi jumpers,
>
> I just renamed master to main so that all the code now appear in the default
> branch.
fine by me
> You probably will have to clone again your local repo to have a clean install
> reflecting the remote repository.
pretty sure
On 18.02.2021 19:19, Michaud Michael wrote:
>
> Hi Ede, jumpers,
whoops, busy. forgot to answer your mail about renaming the github branch. ...
ok, did that just now.
> It seems that the whole build process can be managed from github with github
> actions.
>
>
should we maybe still wrap it in a try/catch so it won't kill rendering? just
to be safe? ..ede
ps. how do we sync svn commits over to github?
On February 8, 2021 11:57:46 PM GMT+01:00, jump-pilot-svn--- via
Jump-pilot-devel wrote:
>Revision: 6671
>
looks like a test like
http://commons.apache.org/proper/commons-imaging/apidocs/org/apache/commons/imaging/Imaging.html#getFormatCompliance-byte:A-
before running Imaging.getImageInfo() might make sense. but it'll likely just
throw an Exception as well. didn't test it.
..ede
On 2/4/2021 11:57,
the commit by Mike seems to have simply added the call Imaging.getImageInfo()
https://sourceforge.net/p/jump-pilot/code/6643/
try to wrap it in try/catch and it should work again. or leave it up to Mike
who fixed the memory routine ;).. ede
ps. All - are we set on the github branch now? if yes
On 1/20/2021 12:54, Eric wrote:
> Hi,
>
> On 19/01/2021 13:13, edgar.sol...@web.de wrote:
>> On 1/19/2021 9:19, Michaud Michael wrote:
>>> Hi Jumpers
>>>
>>> Thanks to Eric's guide, I could initialize openjump project on gitub
>>> (openjump-gis/openjump) and convert it to jts 1.18.
>>>
>>> It is
On 1/19/2021 9:19, Michaud Michael wrote:
> Hi Jumpers
>
> Thanks to Eric's guide, I could initialize openjump project on gitub
> (openjump-gis/openjump) and convert it to jts 1.18.
>
> It is not perfect (I could not convert 1.5 post_release
>
On 1/6/2021 14:08, Michaud Michael wrote:
> Hi Eric, Ede,
>
> I started reading the migration process from Eric (very well done !).
agreed.
> My first problem with the svn2git process was that it stopped on '(no
> author)'. I used Eric instructions to create the authors file again and saw
>
On 05.01.2021 18:31, Angelos Tzotsos wrote:
> Lets re-cap:
>
> We are currently using an iso format for our live system. This is an image
> file with an embeded iso9660 file system. The length of a file's extent on
> disc is stored in a 32 bit value, it allows for a maximum length of just over
seems even to be possible to create an UDF/Joliet combo according to this
https://unix.stackexchange.com/questions/107883/creating-udf-image-in-linux
..ede
Forwarded Message
Subject: Re: [OSGeoLive] Disk (ISO) size limitations
Date: Tue, 5 Jan 2021 19:14:00 +0100
On 05.01.2021
On 05.01.2021 18:31, Angelos Tzotsos wrote:
> Lets re-cap:
>
> We are currently using an iso format for our live system. This is an image
> file with an embeded iso9660 file system. The length of a file's extent on
> disc is stored in a 32 bit value, it allows for a maximum length of just over
On 1/5/2021 14:45, Angelos Tzotsos wrote:
> On 1/5/21 2:39 PM, Angelos Tzotsos wrote:
>> On 1/4/21 10:43 PM, edgar.sol...@web.de wrote:
>>> On 04.01.2021 20:53, Angelos Tzotsos wrote:
On 12/29/20 1:00 PM, edgar.sol...@web.de wrote:
> On 28.12.2020 15:46, Angelos Tzotsos wrote:
>> Hi
On 1/5/2021 13:39, Angelos Tzotsos wrote:
> About the check on iso startup I found this:
> https://askubuntu.com/questions/1231875/how-to-disable-live-system-check-at-startup-booting-in-ubuntu-20-04
that's about changing grub parameter when starting from usb. ideally you'd want
to disable the
On 1/5/2021 13:42, Angelos Tzotsos wrote:
> We should also consider the possibility that adding a new tool to create usb
> drives might prove more difficult for simple users.
please consider testing it first. it's as simple as running a GUI installer and
copying the ISO to the stick. as
On 04.01.2021 20:53, Angelos Tzotsos wrote:
> On 12/29/20 1:00 PM, edgar.sol...@web.de wrote:
>> On 28.12.2020 15:46, Angelos Tzotsos wrote:
>>> Hi all,
>>>
>>> Recently we had a lot of package updates in our development ppa, so we are
>>> releasing OSGeoLive 14.0 alpha4 to test the new updates.
Greetings earthlings, aliens and neither nor,
this epic release marks the end of the long lasting OJ version 1.x series. we
emptied our bug tracker, hence it contains lots of bug fixes and enhancements.
most effort went into raster support. for details check below.
time to release OJ 1.16. any blockers? with some luck we might get it on
OSGeoLive as well.
..ede
___
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
On 28.12.2020 15:46, Angelos Tzotsos wrote:
> Hi all,
>
> Recently we had a lot of package updates in our development ppa, so we are
> releasing OSGeoLive 14.0 alpha4 to test the new updates.
>
> Please download [1], [2], test and report any issues found [3]. Change log
> available at [4].
hey
hey All, Angelos,
incidentally i just came across Ventoy[1] via the Qemu Advent Calendar[2], a
usb stick boot manager that boots ISOs from an otherwise usable data partition.
it supports exFat, NTFS (to name cross platform candidates) among others so
there is actually no 4GB file size limit.
not sure on the how. not familiar with XML2Java myself. but any solution not
throwing errors but using senseful defaults if appropriate sounds reasonable to
me.
it's already dealt with conditionally in
com.vividsolutions.jump.util.java2xml.XML2Java$1.attributeSpecFound(XML2Java.java:147)
so why
Mike,
On 23.12.2020 11:42, Rahkonen Jukka (MML) wrote:
> - about the warning : yes, this warning has been added with the interior
> border capability. Maybe it is not really useful. It throws a warning because
> 'interior' attribute is not really an optional tag, but it is accepted
>
On 12/23/2020 13:15, Rahkonen Jukka (MML) wrote:
> - NoSuchFileException : no idea. There is no plugin name in the stacktrace.
> Seems to happen during OpenJUMP initialization. I don't know what is this
> "OpenJUMP-20201222-r6656-PLUS\conf" file or directory it is looking for.
> Maybe Ede will
On 22.12.2020 16:22, Rahkonen Jukka (MML) wrote:
> Hi,
>
>
>
> I believe that the stack trace below means that the tool does not accept
> negative values. Tools which generate these errors are in the Sextante menu:
that's ok. i don't like nor accept negative values either :)).. have fun
looking good. committed.. ede
On 12/21/2020 13:48, Rahkonen Jukka (MML) wrote:
> Hi,
>
> My SVN client is somehow broken so I send a complete new language file as an
> attachment.
>
> -Jukka-
>
>
> Lähettäjä: Rahkonen Jukka (MML)
> Lähetetty: maanantai 21. joulukuuta 2020 8.41
> Vastaanottaja:
On 12/20/2020 18:10, Michaud Michael wrote:
>
> Hi Jumpers,
>
> Ready for the1.16 release ?
there is a small patch and some changelog amendments on my part still. will
have a look.
> I just clean up a bit the distro by removing 2 jar files : hamcrest (junit
> dependency) and rhino:js (batik
when you are in the right you are. my bad. wonder why i never added it.. thx!
ede
On 12/21/2020 1:00, Michaud Michael wrote:
> Ede,
>
> I've added Imaging, not removed !
>
> Michaël
>
>> envoyé : 20 décembre 2020 à 23:51
>> de : edgar.sol...@web.de
>> à : jump-pilot-devel@lists.sourceforge.net
On 20.12.2020 18:01, jump-pilot-svn--- via Jump-pilot-devel wrote:
> Modified: core/trunk/etc/readme.txt
> ===
> --- core/trunk/etc/readme.txt 2020-12-20 11:59:38 UTC (rev 6650)
> +++ core/trunk/etc/readme.txt 2020-12-20 17:01:37 UTC
once again. this is only necessary if a 4GB limit is taken for granted. in a
time where space becomes abundant and dual layer dvds, 8GB+ usb sticks are
readily available _and_ cheap i'd suggest concentrating efforts to tackle the
limit instead of minimizing the users choice.
consider it an
hey Angelos,
if fat32 is the limiting factor, why is it put as is on the stick and not
extracted? Some tools support that eg. Rufus for windows http://rufus.ie/ and
that works well with pretty much every ISO i put on stick so far.
i am pretty sure that can be done as well on the command line
On 11.12.2020 17:47, Nicolas Ribot wrote:
> Hi ede ! :)
>
> I'm fine thank you, I hope you're well also.
no complaints apart from the pandemical issue ;)
> Yes I followed the activity on the list and am quite happy with OJ 2 !!
nice
> I will have a fresh look on issues and let you know.
elnico :))
how are you? we are nearing a final OJ1 release to continue with OJ2 based on
on the latest JTS. we'll also move development into a git repo, at least that's
the plan at this stage.
any comment or open issues you want to tackle before the release? ..regards ede
On 11.12.2020 17:14,
On 05.12.2020 08:02, Giuseppe Aruta wrote:
>
> This plugin was born as a test to recover useful code of projects destined to
> be abandoned. John Lindsey, the author of the excellent WhiteBox GAT GIS for
> raster in java, wrote to me days ago that he considers his project to be
> legacy and is
the bug is already tagged OJ_future so no hurry there.
we still got 5 open OJ 1.16 bugs[1] which look like they might be solved
already.. ede
[1] https://t1p.de/oix8
On 11/30/2020 10:40, giuseppe.ar...@gmail.com wrote:
> Hi,
> I agree with Michael that ij this step we can consider a good
Peppe,
this looks wrong
ui.GenericNames.cannot-overwrite=Cannot overwrite input layer
should be
ui.GenericNames.cannot-overwrite-input-layer=Cannot overwrite input layer
as you will not be able to use it to message simply "Cannot overwrite!" in a
more generic context!
also. is it possoble
looks like the remaining 4 bugs for OJ 1.16 are mostly fixed or?
hey Mike,
comments inline
On 11/19/2020 9:02, jump-pilot-svn--- via Jump-pilot-devel wrote:
> Revision: 6625
> http://sourceforge.net/p/jump-pilot/code/6625
> Author: michaudm
> Date: 2020-11-19 08:02:57 + (Thu, 19 Nov 2020)
> Log Message:
> ---
> Fix more deeply and
On 11/15/2020 21:10, edgar.sol...@web.de wrote:
> On 15.11.2020 19:24, Michaud Michael wrote:
>> Hi jumpers,
>>
>> I fixed the half-pixel shift problem again. I found much help in geotiff or
>> gdal forums, and most of the time, useful discussions were initiated or
>> documented by Jukka ;-)
>>
On 15.11.2020 19:24, Michaud Michael wrote:
> Hi jumpers,
>
> I fixed the half-pixel shift problem again. I found much help in geotiff or
> gdal forums, and most of the time, useful discussions were initiated or
> documented by Jukka ;-)
>
> Please test and report any problem (r6624+).
hmm, svn
let's wait how the evaluation turns out.. ede
On 27.10.2020 20:53, giuseppe.ar...@gmail.com wrote:
> So it would be better to compare it with also Image-io (ext) speed, memory
> usage and performance
>
> --
> Inviato da myMail per Android
>
> martedì, 27 ottobre 2020, 08:32PM +01:00 da
hey Roberto,
this seems to fall through the cracks ;(. please try and report on the
following when you find the time
> additionally please try your routine with r6564+ but instead of Sextante
> image use the "Open->File->(Select your tifs, click Next)->(keep Use same
> settings for *.tif
but why doesn't it just simply reuse the existing python console? it has access
to all the same functionality! ..ede
On 10/27/2020 14:55, Giuseppe Aruta wrote:
> The idea is to migrate python consolle into CAD toolbox. The advantage is to
> group all together some useful tools that are
works again. i'm wondering where this CAD specific python console can be
activated?
also. why does it exist in parallel to the normal one and why does it need to
be initialized with totally different code? ..ede
On 10/27/2020 13:52, Giuseppe Aruta wrote:
> Yes.
> The problem is on line
>
Peppe,
could you reproduce the issue on your side? i could, but weird thing is, it
complains about a missing method that is definitely there. are you compiling
against the latest OJ-Core?
..ede
On 10/27/2020 13:37, jump-pilot-svn--- via Jump-pilot-devel wrote:
> Revision: 6615
>
the stack looks like a regression i introduced ;(.. should be fixed in r6611
pls try.. ede
On 26.10.2020 17:51, Rahkonen Jukka (MML) wrote:
> Hi,
>
> With OJ 6608 I see too CAD toolbox icons in the main toolbar and they both
> produce an error when pressed:
>
>
> java.lang.NoSuchMethodError:
On 10/13/2020 9:48, Michaud Michael wrote:
> Ede,
>
> Crop operation also uses floats, so I'm not sure it solves the problem.
> Difficult to guess the impact without a try though.
>
> The change may not be trivial as the scale operation which is currently
> performed at first place is also used
hey Mike,
how about cropping first and scaling only the part shown?.. ede
On October 12, 2020 9:19:38 PM GMT+02:00, jump-pilot-svn--- via
Jump-pilot-devel wrote:
>Revision: 6596
> http://sourceforge.net/p/jump-pilot/code/6596
>Author: michaudm
>Date: 2020-10-12 19:19:38 +
thanks will try to reproduce it. additionally could you please test the
Commons-Image Rendering as outlined below? thx.. ede
On 10/2/2020 14:33, edgar.sol...@web.de wrote:
SNIP
>
> additionally please try your routine with r6564 but instead of Sextante image
> use the "Open->File->(Select your
Jukka, Peppe,
way above by payment grade :).. any comment?.. ede
Forwarded Message
Subject:[JPP-Devel] Reading elevation data using Apache Commons Imaging
Date: Sun, 11 Oct 2020 23:28:38 -0400
From: Gary Lucas
Reply-To: OpenJump develop and use
To:
my bad using a jdk.intenal class. will fix it later. ..ede
On 10/10/2020 13:02, Giuseppe Aruta wrote:
> Hi Ede,
> not sure what is the problem. it seems since version 6591
> Peppe
>
>
> ___
> Jump-pilot-devel mailing list
>
hey Rob,
any news wrt. the below? ..ede
On 10/2/2020 14:33, edgar.sol...@web.de wrote:
> no problemo Rob, got a day job still ;)
>
> please try the latest snapshot r6563+ with Peppe's change.
>
> additionally please try your routine with r6564 but instead of Sextante image
> use the
[
https://issues.apache.org/jira/browse/IMAGING-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17208605#comment-17208605
]
edgar soldin commented on IMAGING-265:
--
> If you need one from one of our Maven servers, I can t
you could
1. convert your sea to Multilinestring
2. explode that
3. convert the isles needed to Polygon again
..ede
On 10/5/2020 13:18, Rahkonen Jukka (MML) wrote:
> Hi,
>
> What if I would like to convert all the many holes in the sea polygon into
> islands? We have a tool in OJ that does
no problemo Rob, got a day job still ;)
please try the latest snapshot r6563+ with Peppe's change.
additionally please try your routine with r6564 but instead of Sextante image
use the "Open->File->(Select your tifs, click Next)->(keep Use same settings
for *.tif enabled, Select *Buffered
i just reverted to the use of the ImageIO-Ext TIF reader which worked well in
OJ 1.15, in the hope that it combined with the latest changes will provide a
faster but as stable solution for now.
let's wait how Rob's gonna like it.. ede
On 9/30/2020 17:17, Giuseppe Aruta wrote:
> By the way.
On 9/29/2020 17:31, Giuseppe Aruta wrote:
> I observed that type of raster representation, described by Alberto, only
> when I load some Roberto's raster file using the option *Open
> Layer>Buffered Image (commons imaging)*
> [image: image.png]
that's a completely different code path, which by
On 9/29/2020 16:41, Roberto Rossi wrote:
> Il 29/09/2020 15:00, edgar.sol...@web.de ha scritto:
>> Rob,
>>
>> does that happen with all files or can you pinpoint a specific layer/image?
> Ede,
> I noticed it for the continuos raster ad Digital terrain models (DTM), slope,
> hillshade.
Rob,
can
hmmm,
still there seems to be a difference as SpatialDBDS can read those GPKG
geometries, that DBQuery fails with
Caused by: com.vividsolutions.jts.io.ParseException: Unknown WKB type 233
at com.vividsolutions.jts.io.WKBReader.readGeometry(WKBReader.java:223)
at
On 29.09.2020 19:45, Rahkonen Jukka (MML) wrote:
> select AsGPB(casttoxy(castautomagic(geom))) from test limit 1;
right
select casttoxy(castautomagic(geom)) from random_points
works for my test gpkg data set. wrt. DBQuery
..ede
___
Jump-pilot-devel
On 28.09.2020 21:46, Rahkonen Jukka (MML) wrote:
> We have the robust DB Query that works fine (despite with XYZ geometries but
> that's another thing).
yeah, noticed that DBQuery choked on some geometries from a gpkg test file.
Jukka, would you mind providing some test files for geometry blobs
Rob,
does that happen with all files or can you pinpoint a specific layer/image?
@Peppe: any idea? ..ede
On 9/24/2020 18:37, Roberto Rossi wrote:
> Hi Ede,
> I tested the release 6530
>
> Now there is no any problem in loading the raster file (TIF).
> But there is new problem in visualization.
On 9/29/2020 14:22, Michaud Michael wrote:
> Ede,
>
>
> OJ can't support multiple geometries and it would be a difficult task to make
> this change.
>
> >well, in theory it can. the model as is merely limits geometry to be _only
> one_ of the attributes. as Geometry is a proper attribute type we
On 9/29/2020 13:00, Michaud Michael wrote:
> Hi,
>
> OJ can't support multiple geometries and it would be a difficult task to make
> this change.
well, in theory it can. the model as is merely limits geometry to be _only one_
of the attributes. as Geometry is a proper attribute type we can
On 9/29/2020 12:14, Rahkonen Jukka (MML) wrote:
> edgar.sol...@web.de wrote:
> 29.9. 2020 13.01
>
> On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>>> select geom,
>>> ST_AsText(ST_Centroid(geom)) as centroid from test limit 1;
>
>> do we currently warn/err out if someone actually selects two
On 9/29/2020 11:57, Rahkonen Jukka (MML) wrote:
>> morning Jukka,
>> On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
There would be still some corner cases left (select geom as geometry1,
ST_Centroid(geom) as geometry2...
>>> in theory our features may hold multiple geometries. just one
morning Jukka,
On 9/29/2020 9:15, Rahkonen Jukka (MML) wrote:
>> There would be still some corner cases left (select geom as geometry1,
>> ST_Centroid(geom) as geometry2...
> in theory our features may hold multiple geometries. just one can be shown
> though and the second would be like some
201 - 300 of 3089 matches
Mail list logo
