<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Camptocamp Blog &#187; KML</title>
	<atom:link href="http:///blog/tag/kml//feed/" rel="self" type="application/rss+xml" />
	<link>http://www.camptocamp.com/en/blog/</link>
	<description>Camptocamp weblog</description>
	<lastBuildDate>Fri, 04 May 2012 08:44:05 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Google Summer of Code: MapServer projects</title>
		<link>http://www.camptocamp.com/en/blog/2009/04/google-summer-of-code-mapserver-projects/</link>
		<comments>http://www.camptocamp.com/en/blog/2009/04/google-summer-of-code-mapserver-projects/#comments</comments>
		<pubDate>Wed, 22 Apr 2009 15:10:58 +0000</pubDate>
		<dc:creator>Thomas Bonfort</dc:creator>
				<category><![CDATA[Geospatial Solutions]]></category>
		<category><![CDATA[gsoc]]></category>
		<category><![CDATA[KML]]></category>
		<category><![CDATA[MapServer]]></category>
		<category><![CDATA[OSGeo]]></category>

		<guid isPermaLink="false">http://www.camptocamp.com/en/blog/2009/04/google-summer-of-code-mapserver-projects/</guid>
		<description><![CDATA[The list of accepted students for the 2009 edition of Google Summer of Code has been published yesterday. This year 20 slots were allocated to  OSGEO, 2 of which went to the MapServer project:

KML output: David Kana will be working on adding KML as a native outputformat, allowing MapServer to be plugged in as a [...]]]></description>
			<content:encoded><![CDATA[<p>The list of accepted students for the 2009 edition of Google Summer of Code has been published yesterday. This year 20 <a title="osgeo gsoc projects" href="http://socghop.appspot.com/org/home/google/gsoc2009/osgeo" target="_blank" title="osgeo gsoc projects">slots</a> were allocated to  OSGEO, 2 of which went to the MapServer project:</p>
<ul>
<li>KML output: David Kana will be working on adding KML as a native outputformat, allowing MapServer to be plugged in as a datasource for example in Google Earth. The non trivial points will include determining the subset of MapServer symbology that is natively supported in KML, and switching to a PNG/JPEG outputformat if the number of features inside a given request gets too important. Yewondwossen Assefa and myself will be mentoring this.</li>
<li>Support for reading SVG symbols: Kiran Anjaneya Varma Alluri will be mentored by Daniel Morissette, and will be working on adding a new symbol format to the already supported truetype, pixmap, vector and ellipse ones. This will open up a whole new dimension to MapServer symbology as there are many sources of SVG symbology ready to use around the web.</li>
</ul>
<p>We hope these additions will make it into the 6.0 release that we are scheduling around autumn, just in time for the Sydney FOSS4G !</p>
]]></content:encoded>
			<wfw:commentRss>http://www.camptocamp.com/en/blog/2009/04/google-summer-of-code-mapserver-projects/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Toronto Sprint Code &#8211; PostGIS, remise à plat des fonctions d&#8217;export</title>
		<link>http://www.camptocamp.com/en/blog/2009/03/postgis-remise-a-plat-des-fonctions-dexport/</link>
		<comments>http://www.camptocamp.com/en/blog/2009/03/postgis-remise-a-plat-des-fonctions-dexport/#comments</comments>
		<pubDate>Tue, 24 Mar 2009 16:09:19 +0000</pubDate>
		<dc:creator>David Jonglez</dc:creator>
				<category><![CDATA[Geospatial Solutions]]></category>
		<category><![CDATA[geoJSON]]></category>
		<category><![CDATA[GML]]></category>
		<category><![CDATA[KML]]></category>
		<category><![CDATA[PostGIS]]></category>
		<category><![CDATA[SVG]]></category>
		<category><![CDATA[TinyOWS]]></category>

		<guid isPermaLink="false">http://www.camptocamp.com/en/blog/2009/03/postgis-remise-a-plat-des-fonctions-dexport/</guid>
		<description><![CDATA[Les fonctions d&#8217;export de PostGIS, permettent à partir d&#8217;une géométrie de générer des flux textes dans différents formats.  Parmi les formats existants, on note SVG, GML (2.1.2 et 3.1.1), KML et GeoJson. Suite à la version 1.3.5 et à l&#8217;ajout du support de GeoJson, j&#8217;ai commencé à reprendre les différentes fonctions d&#8217;export pour homogénéiser leurs [...]]]></description>
			<content:encoded><![CDATA[<p>Les fonctions d&#8217;export de PostGIS, permettent à partir d&#8217;une géométrie de générer des flux textes dans différents formats.  Parmi les formats existants, on note SVG, GML (2.1.2 et 3.1.1), KML et GeoJson. Suite à la version 1.3.5 et à l&#8217;ajout du support de GeoJson, j&#8217;ai commencé à reprendre les différentes fonctions d&#8217;export pour homogénéiser leurs comportements, et ensuite reprendre pour certaines l&#8217;organisation du code. Un moyen à la fois pratique et concret pour manipuler les différentes structures de données des géométries PostGIS  internes, et permettre de faire le lien avec l&#8217;application TinyOWS qui réutilise tout ou partie de ces fonctions d&#8217;export.</p>
<p>Le<a title="Toronto Code Sprint" href="http://wiki.osgeo.org/wiki/Toronto_Code_Sprint_2009" target="_blank" title="Toronto Code Sprint"> Toronto Code Sprint</a> a été l&#8217;occasion pour moi de continuer à avancer dans ce process, et faire en sorte d&#8217;améliorer encore la qualité et la robustesse du code de ces fonctions.  L&#8217;ensemble des modifications réalisées étant intégré à la future release 1.4.0 qui doit sortir sous forme d&#8217;une première RC dans un avenir très proche.</p>
<p>A l&#8217;issue de ces journées, en guise de bilan, a été réalisé, pour les fonctions d&#8217;export:</p>
<ul>
<li>Une  réécriture de l&#8217;ensemble de la fonction d&#8217;export ST_AsSVG, avec ajout de tests unitaires et de test de non régression.   Fonctionnelement, son comportement est très proche de celle de la branche 1.3&#8230; sauf qu&#8217;elle corrige un bug bloquant sur  des aggrégations de géométries volumineuses (GEOMETRYCOLLECTION) avant export SVG.</li>
<li>L&#8217;ajout dans les fonctions d&#8217;export GML et GeoJson de la possibilité de générer des CRS dans un format compliant RFC 5165.  Ce format est attendu par les units tests de validation OGC (CITE) pour GML, et il est recommandé comme format préférentiel par la  spécification GeoJson 1.0.  Une évolution suivante sera de pouvoir rajouter la version de la base EPSG utilisée (envisagée pour la 1.5 de PostGIS)</li>
<li> Une analyse et mise en place de la couche bas niveau permettant d&#8217;assurer un futur support des géométries de type Curves pour GML3 et SVG  (ces deux formats permettant une description des curves). Un <a title="Curves for PostGIS" href="http://postgis.refractions.net/pipermail/postgis-users/2008-July/020471.html" target="_blank" title="Curves for PostGIS">post</a> présente les logiques de représentation Curves pour PostGIS<a class="moz-txt-link-freetext" href="http://postgis.refractions.net/pipermail/postgis-users/2008-July/020471.html" class="moz-txt-link-freetext"></a> . Pour rappel les curves ne font pas parti de OGC SFS 1.1,  mais de ISO/SQL:MM part 3, cette dernière spécification devient le nouvel objectif de PostGIS à terme (à l&#8217;horizon de la 2.0).</li>
</ul>
<p>Un premier prototypage pour GML3 pour les arcstrings et circularstrings a été également réalisé (mais non commité). Il reste en effet encore du travail sur les COMPOUNDCURVE et les curves surfaciques (enchainement de LINESTRING et CIRCULARSTRING).</p>
<p>Pour la prochaine release 1.5 de PostGIS, les fonctions d&#8217;import sont également envisagées, i.e pouvoir convertir du GML en Geométrie PostGIS native, et idem pour les KML et le GeoJson&#8230;</p>
<p>Bref encore une foultitude de fonctionnalités qui continuent à faire de PostGIS le SGBD spatial de référence en OpenSource.</p>
<p>Merci à Mark, Regina et Paul pour leurs soutiens, conseils et encouragements sur Toronto et sur la mailing list dev ,</p>
<p><strong>Olivier Courtin, GIS Expert, PostGIS Developper</strong></p>
]]></content:encoded>
			<wfw:commentRss>http://www.camptocamp.com/en/blog/2009/03/postgis-remise-a-plat-des-fonctions-dexport/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

