On Dec 10, 6:32 pm, "maps.huge.info [Maps API Guru]"
<[EMAIL PROTECTED]> wrote:
> Mike,
>
> The problem with D-P and common borders is due to the direction the
> algorithm takes when simplifying the border. For neighboring polygons,
> the algorithm will go in opposite directions for every common line.
> You can see this yourself by just tracing the border with your finger
> around one polygon, then do the same with its neighbor. D-P will
> calculate different simplification results depending on where it
> starts, so slivers and other issues are inevitable. The only way
> around this, and it can be done, is to determine common borders, break
> them into lines, simplify them one at a time, reassemble the polygons,
> check for invalid results (crossing lines, etc.), fix those and you're
> done. Sounds easy, doesn't it?
>
> While it does sound daunting, if you start with the base geometry, the
> Tiger edges shapefile, and simplify that before building the edges
> into larger shapes, the results are easier to deal with.
>
> -John Coryat
>
> http://maps.huge.info
>
> http://www.usnaviguide.com
Hi Mike & John,
Essentially, I agree with one small difference. Except for ties, D-P
is symmetrical in the forward & reverse direction if the same set of
pivot points is used. Unfortunately, D-P was designed for polylines
not for polygons. A closed loop has neither a beginning nor end.
Choosing an initial point is arbitrary. Whatever your choice, the
first split will occur at a remote point diametrically opposite the
first point. D-P will continue to reduce both halves of a common
boundary using a different set of pivots.
I have reduced states & counties to their common boundary line
segments. I have applied a less rigorous smoothing algorithm than D-P
but it does give good results. It is not influenced by initial point
selection. It is done in a single pass rather than recursively like D-
P. I will be happy to explain it in detail.
The results can be seen with:
www.polyarc.us/polybuilder
Eliminating common boundaries reduces the size of the point definition
file by half. I am using a home grown (run length encoding)
compression scheme to further shrink the file size. It is pixel based
rather than Lat/Lon based. Unlike the API, it does not require a zoom
level string. The JS file contains both the compressor & the
decompressor. I explained it in one of my posts several months ago.
I left in some debugging stuff to try to demonstrate a bug to Pamela.
The bug still exists but I have found a way around it.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Maps API" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Maps-API?hl=en
-~----------~----~----~----~------~----~------~--~---
