I've spent a bit of time looking at the polygon with the vertical
stripes. I've output the coordinates of all the inner polygons, and
they look fine on their own. I can get a polygon that looks correct
if I eliminate 3 of the 38 inner polygons. If I only include 2 of
those 3 problem inner polygons, then that polygon also looks good.
However, if I include all of those 3 inner polygons, I get the striped
problem.
So, the simplest problem polygon that I've been able to create has an
outer polygon with 3 inner polygons. It displays with vertical
stripes instead of filled color. I'll gladly send the kml (or kmz) if
anyone is willing to look into this.
Any ideas are appreciated. Thanks.
Bryan
Thanks for the tip by the way, I'm going to try that on the one that's
been giving me a hard time.
Matt
I certainly haven't solved the problem. I'm baffled. Please point to
any related posts.
Was my original post confusing?
Bryan
Try uploading your KMZ to the Files section of this group, and then
pointing to it in a post so we can see if we can duplicate the
problem.
ManoM
I put the file here:
http://groups.google.com/group/kml-support/web/testblm8_py.kmz
I see the western half of the polygon half-filled with vertical yellow
stripes. I'd like to know if others see the same problem and if
anyone knows how to solve the problem.
Bryan
You seem to be running up against a too-many coordinate problem.
Google Earth does have limits on the number of coordinates in a single
geometry. It looks like you're hitting the limit by having too many
combined coordinates. One thing you might look into is line smoothing,
taking way coordinates. Also, you have your coordinates set at a very
high level of precision. Anything out past 6 decimal places is
essentially indistinguishable. I don't know if that's having an
effect, but it might help with smoothing.
ManoM
Thanks for looking at the polygon. Before bringing anything into GE,
I had considered a line simplification routine. But once I saw how
fast GE displayed the results, I decided it wasn't necessary. Given
your adivce I'll probably run the whole input dataset through Douglas-
Peucker and compare the results.
The precision is coming straight from the ogr2ogr conversion which is
reading a double precision format as input. Since I'm doing further
processing with a short script, I can easily remove the extra
precision. Hundredths of centimeters of precision doesn't make sense
with this dataset as you pointed out.
What is Google Earth's limit on the number of coordinates in a single
geometry?
I'll give these suggestions a try and report back. It'll probably be
a few days before I can get back to this. Thanks for the help.
Bryan
There's no hard limit on the number of coordinates. Many factors,
apparently go into it. Do a search on this group, there were some
discussions on the old bbs which were moved over.
ManoM
Thanks for the help. Indeed it makes sense that the number of
vertices is not a hard limit since I was able to create polygons that
displayed fine and then create polygons with fewer vertices that did
not display correctly.
I ended up filtering all the polygons through a line simplification
algorithm but used a different tolerance depending on the size of the
polygon. Thus the only geometries that were visually changed were the
very larges one (~10 out of ~10000), many of which weren't displaying
correctly anyway.
Things look good now.
Bryan
I have the same problem as you described earlier. Some smaller
polygons have vertical stripes (holes) and other larger ones are shown
perfectly. Using multigeometry does help but is an awful job to do for
all countries of the world. Reducing the precision does not help. The
coordinates are read from a Goemdia (GIS) file and saved in the kml
file. Smoothing could help but as far as I know this can not be done
in Geomedia. Which smoothing program did you use to solve the problem
and I wonder if you do not have any problems after the smoothing that
the polygons of adjacent countries do not fit anymore.
Would like to hear from you.
Kind regards,
Bob
On Apr 13, 4:51 pm, Bryan Keith wrote:
> ManoM,
>
> Thanks for the help. Indeed it makes sense that thenumberof
> vertices is not a hard limit since I was able to create polygons that
> displayed fine and then create polygons with fewer vertices that did
> not display correctly.
>
> I ended up filtering all the polygons through a line simplification
> algorithm but used a different tolerance depending on the size of the
> polygon. Thus the only geometries that were visually changed were the
> very larges one (~10 out of ~10000), many of which weren't displaying
> correctly anyway.
>
> Things look good now.
>
> Bryan
>
> On Apr 9, 3:20 pm, ManoM wrote:
>
> > Hi Bryan,
>
> > There's no hard limit on thenumberofcoordinates. Many factors,
> > apparently go into it. Do a search on this group, there were some
> > discussions on the old bbs which were moved over.
>
> > ManoM
>
> > On Apr 9, 2:00 pm, Bryan Keith wrote:
>
> > > ManoM,
>
> > > Thanks for looking at the polygon. Before bringing anything into GE,
> > > I had considered a line simplification routine. But once I saw how
> > > fast GE displayed the results, I decided it wasn't necessary. Given
> > > your adivce I'll probably run the whole input dataset through Douglas-
> > > Peucker and compare the results.
>
> > > The precision is coming straight from the ogr2ogr conversion which is
> > > reading a double precision format as input. Since I'm doing further
> > > processing with a short script, I can easily remove the extra
> > > precision. Hundredths of centimeters of precision doesn't make sense
> > > with this dataset as you pointed out.
>
> > > What is Google Earth's limit on thenumberofcoordinatesin a single
> > > geometry?
>
> > > I'll give these suggestions a try and report back. It'll probably be
> > > a few days before I can get back to this. Thanks for the help.
>
> > > Bryan
>
> > > On Apr 9, 2:28 pm, ManoM wrote:
>
> > > > Hi Bryan,
>
> > > > You seem to be running up against a too-many coordinate problem.
> > > > Google Earth does have limits on thenumberofcoordinatesin a single
> > > > geometry. It looks like you're hitting the limit by having too many
> > > > combinedcoordinates. One thing you might look into is line smoothing,
> > > > taking waycoordinates. Also, you have yourcoordinatesset at a very