Polygon only filled in patches

[indiie]

Hi

This is my first post. I've tried searching for a solution to my problem but couldn't find anything.

I've typed some KML that displays polygons that have solid fill colours. Most of the polygons are completely filled as expected, but a couple only get some bits filled instead of the entire thing.

Here is a screenshot:


It gives the appearance that the colour is running from the polygons above. Sadly this is not the look I'm going for

There are two out of 28 polygons that aren't completely filled. One is the large patch of area toward the bottom and left (to the border) and the other is smaller and over on the right coast line.

All polygons have the same style attributes as follows (even though each has it's own <Style> element - unnecessary I know):
<PolyStyle>
<color>FF00AA00</color>
<fill>1</fill>
</PolyStyle>

I isolated the large polygon that isn't displaying into it's own KML file and I still get the same effect as per below:


Changing zooming, altitude, rotation or fill slider makes no difference.
The KML file to display this is 9MB (about 38000 coordinates for that one big polygon) and I'm on dial-up but I've attached the relevant (I assume) snippet. The only thing I've removed is about 38000 lines of coordinates. NOTE: THIS FILE IS NOT MEANT TO BE PARSED BY GE - IT'S JUST FOR VIEWING VIA TEXT EDITOR. I've intentionally put an incorrect line in amongst the coordinates.

This is just for a university assignment so excuse the potentially dodgy KML code.

I tried adding various extrude, tesselate and altitudeMode elements but it made no difference. I did see a few posts referring to the ordering of the coordinates (listing them clockwise vs anti-clockwise) making a difference to the shade of the colour. But this doesn't seem to be a shade problem. Does anyone know of a program that will reverse the order of my coordinates? I could write one but why reinvent the wheel?

Any suggestions on how to get the polygons to be filled completely would be much appreciated.

Ta.
Glen.

[ManoM]

There doesn't appear to be anything wrong with your KML. I cannot reproduce your results because I don't have all of your file, and the four coordinates you gave are at altitude 0.

I noticed you're using KML 2.0, not 2.1, and I'm wondering if you are using GE 3.0. You might try upgrading to the latest beta version and trying then.

Also, I'm wondering if you change your angles, do you get different results?

[joelhans]

You need to either set your elevation values for the coordinates. Try going into the properties of the layer and adjusting the elevation - this will extrude the polygon into a 3D layer. Or you can set the polygon with a "Tessellate" property.

Check out this link: web page


I hope that helps.

Joel joel...@gmail.com

[Forkboy2]

I'm pretty sure this is a bug. I've seen it too with very large and complex polygons. Probably a memory limitation of some sort. Does the size and complexity of the affected polygons seem to be greater than those that work?

Matt

[indiie]

Quote:

---

There doesn't appear to be anything wrong with your KML. I cannot reproduce your results because I don't have all of your file, and the four coordinates you gave are at altitude 0.

I noticed you're using KML 2.0, not 2.1, and I'm wondering if you are using GE 3.0. You might try upgrading to the latest beta version and trying then.

Also, I'm wondering if you change your angles, do you get different results?

---

I changed doc to use 2.1 schema and installed GE 4 Beta but still same problem.
Changing angles makes no difference.

All of the altitude coordinates for all of the polygons are set to zero. This hasn't affected the other polygons that dispay OK. I tried setting all altitudes to value 20 and added
<extrude>1</extrude>
<altitudeMode>relativeToGround</altitudeMode>
This resulted in the fill turning black (instead of green) and being even more patchy (less fill present).

I then also tried:
<extrude>1</extrude>
<altitudeMode>clampToGround</altitudeMode>
<tessellate>1</tessellate>

with altitudes at 20 but still have the same patchy green problem.

Quote:

---

You need to either set your elevation values for the coordinates. Try going into the properties of the layer and adjusting the elevation - this will extrude the polygon into a 3D layer. Or you can set the polygon with a "Tessellate" property.

Check out this link: web page


I hope that helps.

Joel joel...@gmail.com />

---

Tried it as outlined above. The problem remains.

Quote:

---

I'm pretty sure this is a bug. I've seen it too with very large and complex polygons. Probably a memory limitation of some sort. Does the size and complexity of the affected polygons seem to be greater than those that work?

Matt

---

The large polygon that won't display is probably the largest most complex in the KML document. The second polygon that won't display, which is further over to the right of the picture on the coastline, isn't large in area but may very well be the second most complex with around 24000 coordinates and 50 innerBoundaries (includes boundaries for some small islands off the coast).

I think your hypothesis makes most sense thus far Matt.

I've separated this smaller polygon into it's own file and still have the same problem. File is attached.

I doubt this is relevant but FYI this project involves taking a MIF data file in the MapInfo (another mapping application) propiertary format and converting it into a KML file. The sample data we have been supplied are the Queensland, Australia federal electoral boundaries. That is what my polygons represent.

[ManoM]

So looking carefully at your KML, it appears you are trying to use the innerBoundaryIs to add an additional area, outside the outerBoundaryIs coordinates. To display normally, innerBoundaryIs coordinates should be entirely within the outerBoundaryls. Also, there should only be one outerBoundaryIs and one innerBoundaryIs. You have several innerBoundaryIs tags.

I'd suggest separating out each of the innerBoundaryIs and making them a separate polygon. I've attached a file to show what I mean.

ManoM

[CCB2006]

Quote:

---

Quote:

---

All of the altitude coordinates for all of the polygons are set to zero. This hasn't affected the other polygons that dispay OK. I tried setting all altitudes to value 20 and added
<extrude>1</extrude>
<altitudeMode>relativeToGround</altitudeMode>
This resulted in the fill turning black (instead of green) and being even more patchy (less fill present).

Quote:

---

I'm pretty sure this is a bug. I've seen it too with very large and complex polygons. Probably a memory limitation of some sort. Does the size and complexity of the affected polygons seem to be greater than those that work?

Matt

---

The large polygon that won't display is probably the largest most complex in the KML document. The second polygon that won't display, which is further over to the right of the picture on the coastline, isn't large in area but may very well be the second most complex with around 24000 coordinates and 50 innerBoundaries (includes boundaries for some small islands off the coast).

I doubt this is relevant but FYI this project involves taking a MIF data file in the MapInfo (another mapping application) propiertary format and converting it into a KML file. The sample data we have been supplied are the Queensland, Australia federal electoral boundaries. That is what my polygons represent.

---

I'm pretty sure the reason your polygon is turning black is the nodes in the polygon are 'clockwise' order, rather than anti-clockwise. I know that MapInfo doesn't care what order the nodes are in, but GoogleEarth does. (I can't recall, though, if only the outerBoundary has to be clockwise, or all polygons.)

Contrary to what another poster wrote, you can have more than one inner boundary. I've attached a sample file to demonstrate.

(Note that you need to add an additional line to the innerBoundary so the inner polygons are closed. In the attached file, the first pair of coordinates are duplicated as the last coordinates.)

As for the incomplete drawing, or the 'patchy' drawing, I believe that is due to trying to map a large flat object over a curved earth. To demonstrate, reduce the altitude in the attached file. At ~100m, the patchiness will appear in the large object.
In a thread several months ago a contributor offered a formula for calculating the altitude you would need to insure smooth drawing, based on an object's size.
Hope this helps.

[indiie]

First I'd like to say thanks to everyone that replied. It's nice to actually get help in a support forum, which isn't always the case.

I wasn't aware that it was only one innerBoundaryIs per Polygon. I didn't see that limitation mentioned anywhere in the KML 2.0 spec I was using. Ta.

The problem is that I need all of those polygons to be considered a single entity that only has one description ballon and colour shading using the slider scale can be manipulated for all of those polygons together.

Also, the larger polygon region (not originally uploaded) only had a single innerBoundary. Even after removing this it still wouldn't display with correct fill. I did some debugging and narrowed down the problem, although it doesn't seem to be static.

I first found that having an outerboundary with 32143 coordinates was OK but when I added the 32144th, it didn't display right. After some more testing and investigation I found that the number of coordinates 'allowed' varied! It started working with a greater number. I thought it might be the location of the coordinates that was the problem. Or maybe the memory thing again?

Anyway, I've uploaded the large polygon file that had the problem where it won't display correctly. Try removing the last coordinate and it should then display correctly. Any ideas on why this is?

I found a workaround to simplify what I need to display so I don't really need to know, but just curious now.

[indiie]

Quote:

---

Contrary to what another poster wrote, you can have more than one inner boundary. I've attached a sample file to demonstrate.

(Note that you need to add an additional line to the innerBoundary so the inner polygons are closed.

---

By this do you mean you have to manually add the last coordinate which is a copy of the first? Or are you referring to some line of KML that does this for you?

Quote:

---

As for the incomplete drawing, or the 'patchy' drawing, I believe that is due to trying to map a large flat object over a curved earth. To demonstrate, reduce the altitude in the attached file. At ~100m, the patchiness will appear in the large object.
In a thread several months ago a contributor offered a formula for calculating the altitude you would need to insure smooth drawing, based on an object's size.
Hope this helps.

---

I can't actually see any fill (hence no patchiness) at all in the objects displayed by the KML file you attached. Which is strange seeing as it's defined in the style.

Yeah I found that formula when first searching for an answer but it looked a little too complex (and wasn't explained well) for my liking . But thanks for the info.

[CCB2006]

Quote:

---

Quote:

---

Contrary to what another poster wrote, you can have more than one inner boundary. I've attached a sample file to demonstrate.

(Note that you need to add an additional line to the innerBoundary so the inner polygons are closed.

---

By this do you mean you have to manually add the last coordinate which is a copy of the first? Or are you referring to some line of KML that does this for you?

---

I'm not sure what you mean. In the tool I wrote to produce KML, I added code to generate the extra set of coordinates. If whatever method you use to produce the KML doesn't include the extra coordinates, you will have to add them. There is no 'line of KML' to automatically fix innerBoundaries.

Quote:

---

I can't actually see any fill (hence no patchiness) at all in the objects displayed by the KML file you attached. Which is strange seeing as it's defined in the style.

---

Are you using the 4.0 beta? The kml I attached displays correctly in GoogleEarth 3.x, but not in 4.0, and I don't know why. Until Google publishes a schema to help us validate KML, I suspect it will be a tedious trial-and-error effort to figure out why something that displays correctly in 3.x is broken in 4.0.

[indiie]

Quote:

---

---

Yes using GE 4.0 beta. Looking at our sample data supplied it appears all of the last coordinates match the first.

[tekgergedan]

Hi indiie,

Outer polygon must contain all the inner ones. Your 1st inner polygon which covers the Fraser Island is not contained by the outer polygon.

To be sure, remove all the 1st inner polygon's coordinates and it works fine.

You must expand the outer polygon to contain that island.

Code:

---

<Polygon>
	<outerBoundaryIs>
		<LinearRing>
			<coordinates>...</coordinates>
		</LinearRing>
	</outerBoundaryIs>
	<innerBoundaryIs>
		<LinearRing>
			<coordinates>1st inner</coordinates>
		</LinearRing>
		<LinearRing>
			<coordinates>2nd inner</coordinates>
		</LinearRing>
		<LinearRing>
			<coordinates>3rd inner</coordinates>
		</LinearRing>
	</innerBoundaryIs>
</Polygon>

---

[indiie]

Quote:

---

---

Hi

Someone already mentioned that that was the problem, thanks. But do you have any suggestions as to why this KML file:
http://bbs.keyhole.com/ubb/download.php?Number=639905

doesn't display with correct fill? But it does if you remove the last coordinate in the outer polygon. Note that this one has no inner polygons.

[tekgergedan]

That kml is related to a malfunctioning. In fact, your placemark is NOT a polygon. In a polygon, the starting and ending coordinates must be the same. In GE, this is shown by the last point not colored (the path ending with no red or blue point) when you are editing the path.

Having it working after the deletion of the last point is a malfunctioning of the polygon feature. It was also discussed several times before.

[Bruno_Bowden]

The patches of polygon that you're seeing is caused by driver problems. This happens more frequently with large polygons with a lot of detail. The way to fix it is to upgrade your graphics card drivers. Depending on your graphics and whether this is on a laptop, this may be difficult to do.

The suggestion of switching to "relativeToGround" will work as the polygons are drawn differently then (though you'll need to give it a positive altitude to make sure it doesn't intersect with the terrain).