[GRASS-dev] [GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Maris Nartiss]

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 <mlennert at 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).
>