Hi Ryan,<div><br></div><div>I know you guys are pretty maxed out on your developer time commitments, but I'm pretty sure that the FDO project would welcome more direct participation by Safe if there's any interest on your side.</div>
<div><br></div><div>Haris / SL-King are using the SpatiaLite provider with several clients, so there is some development impetus there, but apart from that there has been limited community uptake so most improvements thus far have been specific to SL-King's use. Safe's use of this provider would raise its profile for sure, but there may still be a need for extra help / resources to add additional capabilities.</div>
<div><br></div><div>The process of writing an RFC for bringing the provider into the official fold is a fair bit of overhead, but I'll see if I can find some cycles to do this and a PSC sponsor :)</div><div><br></div>
<div>When Haris addresses these issues, what FDO version are you targeting for compilation?</div><div><br></div><div>Jason<br><br><div class="gmail_quote">On 23 March 2011 11:30, Ryan Proulx wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Perhaps this is not quite the right forum, but despite being successful using the new SL-King SpatiaLite FDO Provider (version 0.1.2 as made
available <a href="http://www.sl-king.com/fdospatialite" target="_blank">here</a>) to read from SpatiaLite databases we have encountered a few issues with encoded column names when round tripping to and from SpatiaLite. <br>
<br>Using the provided sandbox source code, it appears that though the provider writes the encoded column name correctly, mapping the UTF-16 name in FDO to the UTF-8 string using the FDOStringP class, when reading the opposite mapping is not occurring. Instead in c_FdoSlite_API2::DescribeTableProperties there is an attempt to use the 'multibyte_to_wide' macros. These macros are ineffective in this context as they only widen the data type (from char* to wchar_t*) but do not change the encoding (from UTF-8 to UTF-16) as expected by the FDO. An alternative might have been to use the UTF-16 API calls instead but in the name of parallelism the FDOStringP seemed more appropriate.<br>
<br>I have provided a very simple patch file to correct the issue and if it meets with your approval would like to see it in the next version of the provider (if it has not been fixed already).<br><br> Do you have a rough estimate when we will see the next version of this provider or better yet become a complete citizen of FDO?<br>
<br>Thanks<br><font color="#888888">
ryan<br>
</font><br>_______________________________________________<br>
fdo-users mailing list<br>
<a href="mailto:fdo-users@lists.osgeo.org">fdo-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fdo-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fdo-users</a><br>
<br></blockquote></div><br></div>