[EMAIL PROTECTED] wrote on 03/06/2007 03:42:10 PM:
> This approach will leave wfs 1.1 and gml3 encoding out in the cold since > it takes a different approach to this. It relies on coming up with > defined mappings from java classes to xml schema data types. I admit > that in the case of dates the mapping is not clean. GML3 (and maybe wfs1.1? haven't looked) encode ISO 19108. This can not only handle "calandars", but ordinal reference systems. We've made GeoAPI interfaces for 19108 and a partial implementation (calandar-only) which needs to be dropped into the geotools code base. However, this does bring to light a potential issue: is there a single orthodox FeatureModel<->XML encoding in the code base? We may have to factor that out so that we can have a GML2 plugin coexist with a GML3.1.1 plugin, coexisting with a 19139 plugin, coexisting with custom schema encoding plugin (ala 19118). None of the following are <xs:date> etc. <gml:timePosition>2002-11-25T13:20:20</gml:timePosition> <gml:timePosition indeterminatePosition="after">1994</gml:timePosition> <gml:timePosition indeterminatePosition="now"></gml:timePosition> <gml:timePosition frame=”http://my.big.org/TRS/GPS”>25876321.01 </gml:timePosition> <gml:timePosition frame="http://my.big.org/TRS/archaeology";> http://my.history.org/eras/bronzeAge </gml:timePosition> <gml:timePosition frame=”http://my.big.org/TRS/calendars/japanese” calendarEraName="Meiji">0085- 03</gml:timePosition> Bryce ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
