As goes for encoding issues - I would like to see one change made for attribute data handling. As correct encoding needs to be used in quite many places (Python 3; multiple output formats as OGR ESRI Shapefile; KML etc.), I would propose to add data encoding to the database connection configuration. Current approach of "single encoding for all attribute data" is flawed on multilingual systems, as each of multilingual data source might be in different encoding thus setting a single encoding in GUI preferences is only a road to failure. Attempts to guess correct data encoding based on current system locale also are part of current problem. I have on my todo list some changes to make locale switching from GUI even more robust, still it is not possible to work around all of problems. Unfortunately if we are planning to support data export from GRASS, attribute data can not be "just a stream of binary data", as they need also correct metadata.
Providing a datasource encoding metadata for dblink is a straight forward thing (needs a discussion about fail-back mechanism for existing dblink configurations). Worth of discussion is the question of enforcing of encoding - should dbconnect always issue "set names FOO"? Should there be an option to switch off enforcing? As I am opportunistic programmer (you could call it also being short-sighted) - any other potential issues coming up from my idea? As there is GRASS 7.0 branch and trunk - does it mean that such changes have to wait till 7.1 (no new features policy)? I'm sorry, but not everyone had a chance to participate in Vienna coding event. Maris. 2014-04-07 12:22 GMT+03:00 Moritz Lennert <mlenn...@club.worldonline.be>: > > On Linux GRASS7 already works marvelously (although encoding issues in the > GUI just seem to be multiplying, but that's a discussion for bug tickets not > here). > _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
