Content-Type: |
multipart/related; boundary=089e013d1dc62188f804e1076dbd |
Sender: |
|
Subject: |
|
From: |
|
Date: |
Mon, 8 Jul 2013 18:18:38 -0400 |
In-Reply-To: |
|
MIME-Version: |
1.0 |
Reply-To: |
|
Parts/Attachments: |
|
|
On Fri, Jul 5, 2013 at 4:16 PM, george.richardson <
[log in to unmask]> wrote:
> **
> First of all, I'm not sure if the mailing list is the proper place to post
> a bug report. If it is not, someone please kindly inform me.
>
Actually this is indeed the right place to report GeoMASON bugs.
>
> ... I noticed that the UI Portrayal was failing to display the polygons
> of certain countries at all, notably South Africa and Kazakhstan. On
> closer inspection, it was in fact displaying part (a very small part) of
> the country's polygon, like a small island off the coast. I also noticed
> that the un-displayed countries all had shapefile polygons which had
> "holes" in them. Digging through the code, I found what I believe to be
> the error in the class ShapeFileImporter.java, from the latest GeoMason
> source code. (sim.io.geo.ShapeFileImporter.java)
>
You are correct. I was able to reproduce this error whereby holes in
multpolygons were not being properly handled. The following image shows a
big ole hole where Kazkhstan should be. The dot in center is for the Baikonur
Cosmodrome, which you pointed out.
[image: Inline image 1]
I committed a bug fix to SVN. So, now we get this:
[image: Inline image 2]
In case you're curious, here's a snippet from ShapeFileImporter.java:
LinearRing [] holesArray = null;
if (! holes.isEmpty())
{
holesArray = new LinearRing[holes.size()];
holes.toArray(holesArray);
}
if (shells.size() == 1)
{ // single polygon
return geomFactory.createPolygon(shells.get(0), holesArray);
}
else
{ // mutipolygon
Polygon[] poly = new Polygon[shells.size()];
for (int i = 0; i < shells.size(); i++)
{
poly[i] = geomFactory.createPolygon(parts[i], holesArray);
}
return geomFactory.createMultiPolygon(poly);
}
I.e., it's very similar to your code with one significant change. I noted
that handling polygonal holes was orthogonal to whether we're dealing with
single or multipolygons so now holes are handled separately.
Thanks for the bug report and solution, George!
Cheers!
Mark
--
[log in to unmask]
|
|
|