moin Jukka, On 18.03.2015 06:48, Rahkonen Jukka (MML) wrote: > Hi Ede, > > The problem is the opposite. Changing schema is conscious choice but when > user saves data to an existing shapefile the changed schema may not be saved > because old field definitions Number(X.Y) and maybe also Character(X) are > cached.
so it should result or in an error >DBF has only Number and Double for numbers >http://www.clicketyclick.dk/databases/xbase/format/data_types.html and all the >OJ data types must be mapped into Number(X.Y) format. What happens if user >changes existing Number(10.0) that old OJ versions read as Integer but new one >as Long into Integer, Tiny, or Small? Will the number format change or not? >Should it change? as datatypes in OJ are merely meta information assigned by the user or taken from the source (db, file) for the user to fiddle with, they don't actually change the way we handle the data in OJ. internally from a processing standpoint it is all numbers/strings/boolean in java datatypes. can you think of an issue that could arise? why should we read the numbers as TINY or SMALL? to stay legacy compatible we should stick when reading shapefiles to INTEGER and only if 2^31 is not enough choose LONG. you said it yourself "DBF has only Number and Double", so no need interpret more detailed definitions into the format ;) Mike: how is reading currently handled wrt. the above? ..ede ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
