Re: Horae - KDE-calculation problems

[Stefan Steiniger]

Hey Tanja,

thanks for getting back to me on your two problem cases.
It seems like you discovered a bug with the program.
bug (1) the grid size is not big enough.
bug (2) the generated contours are shifted.

I weird thing is that I had similar results before (2 years ago) and I
thought I would have fixed it. I tested also what happens if the x
coordinate is made positive, but no success.

I will need to "debug", and see what is going on which will take time. I
hope I can find time on Monday for that (which does not necessarily mean
I can solve the problem). Meanwhile maybe you can have a look at HRT[1]
in case you have ArcGIS? But note, that HRT uses a different h_ref value
(multiplied with a Kernel type specific value ...).

I hope to get back to you soon,
stefan

[1] http://flash.lakeheadu.ca/~arodgers/hre/

Am 17.03.13 08:28, schrieb Tanja Himmel:
> Hey Stefan,
>
> thanks for your advice. you are right, it seems as if the problem was
> applying inappropriate cell size. I also tried some other samples from
> my dataset and it worked too. Nevertheless, when I calculate KDE
> choosing bandwith by LSCV, then in some samples it works without any
> conflict but in some samples it looks as if the raster created doesn't
> cover all datapoints and probability contours can't be created...for
> those samples I varied cell size. At some cell sizes it then works, but
> for some samples no proper raster can be created, no matter which cell
> size applied.
>
> Another problem is that in some samples, where raster could be created
> from KDE with LSCV-option and probability contours were analysed, they
> seem to be shifted refered to the raster. Do you have an idea why that
> happens?
>
> Attached I send you one sample with some datapoints, where no proper
> raster could be created (atelopus_062) and one sample where the problem
> regarding shifting probability contours occured (atelopus_021). Maybe
> you find some time to have a closer look on them, that would be great!
>
> Thanks a lot,
> Tanja
>
>
> -----Urspr�ngliche Nachricht----- From: Stefan Steiniger
> Sent: Tuesday, March 12, 2013 4:33 PM
> To: Tanja Himmel
> Subject: Re: Horae - KDE-calculation problems
>
> Hi Tanja,
>
> I just checked with the data you send and it worked for me too.
> Now, maybe just to make sure, can you apply the following function on
> the layer: Edit>Extract>Extract layers by geometry type.
>
> Afterwards, only one layer should be created. If that is the case, then
> you have really only one geometry type and the error message would be
> wrong.
>
> In that case, I am without any idea what the reason may be and it would
> be best to see the whole dataset - if that is possible. Btw. you did
> send me only one shp file. I am not sure if you also have attribute
> data, but in that case, a shapefile consists of at least 3-5 files that
> all have the same name but different endings. *.shp contains geometries
> while *.dbf for instance contains the attribute data. So if you feel
> like sending me you dataset, then it is best to zip all files with the
> same name.
>
> Actually, when I tested with your sample data, I saw that points are
> very close (3-5m distance), whereas the grid size for the raster is set
> to 25m. So for the sample data you sent, I applied a bandwidth h = 3.2m
> and a grid size of 0.4m. Perhaps that is why there is some problem too,
> i.e. the raster grid size? (Just see in wikipedia that "Atelopus" is a
> frog, 3m point distance makes totally sense then, I think ;) I was
> dealing with grizzly bears before when writing the tools, so my distance
> are some hundreds of meters or km.)
>
> let me know if you make progress or not, so we can try and find a solution.
>
> cheers,
> stefan
>
> Am 12.03.13 06:43, schrieb Tanja Himmel:
>> Dear Stefan,
>> I� ve checked the geometry of my dataset- it looks like it is single
>> point (all features), not multipoint as you suggested. So I followed
>> your instructions and copied some data points into a new layer. attached
>> you can find the shape-file with some points of the dataset. Hope you
>> can help me!
>> thanks for your support!
>> kind regards,
>> Tanja

[Stefan Steiniger]

Hey Tanja,

I found some time to check whats happens and even could find a fix. So
in my version it works now with the 2 datasets of you (after assigning
weight values of 1.0, using h=0.4 and cell size=0.04 it works now, while
it previously did not for that particular cell size).

I will attach two files:
- movantools_mar2013.jar
- ojsextante_binding_mar2013.jar

While OpenJUMP not being run, copy these two files in your OpenJUMP
installation sub folder: "YourOJHoraeFolder/lib/ext/"

Afterwards, delete the two old files, named:
- movantools_feb2013.jar (if you used the latest HoRAE version,
otherwise the similar named file starting with movenatools_monthyear.jat)
- ojsextante_binding_oct2012.jar

Then start-up OpenJUMP again.
The former contained the bug that was responsible for creating too small
rasters, and the latter contained the bug causing a shifted contour line.

Please let me know if it works for you too. If yes, then I can make a
new HoRAE release for everyone to download.

Thanks for making me aware of the two problems, and hopefully there
aren't more problems ;)
stefan


PS: In case someone had similar problems I cc to the user list.

Am 17.03.13 08:28, schrieb Tanja Himmel:
> Hey Stefan,
>
> thanks for your advice. you are right, it seems as if the problem was
> applying inappropriate cell size. I also tried some other samples from
> my dataset and it worked too. Nevertheless, when I calculate KDE
> choosing bandwith by LSCV, then in some samples it works without any
> conflict but in some samples it looks as if the raster created doesn't
> cover all datapoints and probability contours can't be created...for
> those samples I varied cell size. At some cell sizes it then works, but
> for some samples no proper raster can be created, no matter which cell
> size applied.
>
> Another problem is that in some samples, where raster could be created
> from KDE with LSCV-option and probability contours were analysed, they
> seem to be shifted refered to the raster. Do you have an idea why that
> happens?
>
> Attached I send you one sample with some datapoints, where no proper
> raster could be created (atelopus_062) and one sample where the problem
> regarding shifting probability contours occured (atelopus_021). Maybe
> you find some time to have a closer look on them, that would be great!
>
> Thanks a lot,
> Tanja
>
>

> -----Urspr锟斤拷ngliche Nachricht----- From: Stefan Steiniger

>> I锟斤拷 ve checked the geometry of my dataset- it looks like it is single