<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Tiled Vectors in Virtual Earth</title>
	<atom:link href="http://spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/feed/" rel="self" type="application/rss+xml" />
	<link>http://spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/</link>
	<description>Geospatial Technology, Web Mapping and Spatial Services</description>
	<lastBuildDate>Fri, 10 Feb 2012 19:09:18 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Lance Dyas</title>
		<link>http://spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/#comment-8228</link>
		<dc:creator><![CDATA[Lance Dyas]]></dc:creator>
		<pubDate>Thu, 28 Feb 2008 22:17:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/#comment-8228</guid>
		<description><![CDATA[Unless you are really careful to treat the topologically identical segments as identical and process them the same.. you get the visual horror story in that demo... Being topological in many cases is something people will know - even though the data doesn&#039;t have its topology stored with it we &quot;know&quot; those adjacent polys are supposed to be the same.  D-P is well pretty damn slow on the fly which may be why they have &quot;hem an hawed&quot; about using it. My google maps extension GeoXml does use D-P either on the fly or with pre-encoded vector data but errs on the side of not simplifying far enough...
relevant page is parsing gml and using D-P on the fly. 
http://www.dyasdesigns.com/geoxml/gmlusa.htm]]></description>
		<content:encoded><![CDATA[<p>Unless you are really careful to treat the topologically identical segments as identical and process them the same.. you get the visual horror story in that demo&#8230; Being topological in many cases is something people will know &#8211; even though the data doesn&#8217;t have its topology stored with it we &#8220;know&#8221; those adjacent polys are supposed to be the same.  D-P is well pretty damn slow on the fly which may be why they have &#8220;hem an hawed&#8221; about using it. My google maps extension GeoXml does use D-P either on the fly or with pre-encoded vector data but errs on the side of not simplifying far enough&#8230;<br />
relevant page is parsing gml and using D-P on the fly.<br />
<a href="http://www.dyasdesigns.com/geoxml/gmlusa.htm" rel="nofollow">http://www.dyasdesigns.com/geoxml/gmlusa.htm</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tim Maddle</title>
		<link>http://spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/#comment-8227</link>
		<dc:creator><![CDATA[Tim Maddle]]></dc:creator>
		<pubDate>Sat, 02 Feb 2008 03:58:01 +0000</pubDate>
		<guid isPermaLink="false">http://www.spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/#comment-8227</guid>
		<description><![CDATA[The demo works smoothly for me in FF, but crashes my IE6.  Anyone else have the same result?  For now, I&#039;m happy enough to stick my mapserver generated raster overlays, but a system for handling large amounts of vector data would be great.]]></description>
		<content:encoded><![CDATA[<p>The demo works smoothly for me in FF, but crashes my IE6.  Anyone else have the same result?  For now, I&#8217;m happy enough to stick my mapserver generated raster overlays, but a system for handling large amounts of vector data would be great.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Smith</title>
		<link>http://spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/#comment-8226</link>
		<dc:creator><![CDATA[Dave Smith]]></dc:creator>
		<pubDate>Sat, 02 Feb 2008 02:56:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.spatiallyadjusted.com/2008/02/01/tiled-vectors-in-virtual-earth/#comment-8226</guid>
		<description><![CDATA[This was the same issue I pointed out to the VE folks with their vector support - when they announced GeoRSS support, I was immediately past points and on to vectors, same with KML - and found that they appear to drop vertices indiscriminately.   Perhaps an &quot;drop every nth vertex&quot; algorithm.  But the problem noted was exactly as described, not always the same corners getting lopped off, and so on - with adjoining polygons, it results in strange and inconsistent gaps and overlaps.

It&#039;s got nothing to do with topology, of course, because GeoRSS, KML and similar vector formats do not have any topology to know that they in fact have any relationship or common segments with the adjoining features.  On the other hand, an approach that takes a consistent approach with respect to angular relationships, to preserve critical detail, is more likely to give more desirable results...

I certainly threw the Douglas Peucker notion at Microsoft several months back, when I saw the flaky vector results I was getting - so far they have only responded with the option to turn off generalization and a suggestion they might look at it sometime.]]></description>
		<content:encoded><![CDATA[<p>This was the same issue I pointed out to the VE folks with their vector support &#8211; when they announced GeoRSS support, I was immediately past points and on to vectors, same with KML &#8211; and found that they appear to drop vertices indiscriminately.   Perhaps an &#8220;drop every nth vertex&#8221; algorithm.  But the problem noted was exactly as described, not always the same corners getting lopped off, and so on &#8211; with adjoining polygons, it results in strange and inconsistent gaps and overlaps.</p>
<p>It&#8217;s got nothing to do with topology, of course, because GeoRSS, KML and similar vector formats do not have any topology to know that they in fact have any relationship or common segments with the adjoining features.  On the other hand, an approach that takes a consistent approach with respect to angular relationships, to preserve critical detail, is more likely to give more desirable results&#8230;</p>
<p>I certainly threw the Douglas Peucker notion at Microsoft several months back, when I saw the flaky vector results I was getting &#8211; so far they have only responded with the option to turn off generalization and a suggestion they might look at it sometime.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

