On Sun, Jul 4, 2010 at 5:48 PM, Hamish <hamis...@yahoo.com> wrote: >> Hamish wrote: >> > as you found, on top of that, grass 6 titles (cats+hist) are >> > going to be limited to RECORD_LEN chars. an update of the meta- >> > data backend remains a major TODO for grass 7. > Glynn: >> FWIW, I've re-written this in r42695. >> >> The fields of "struct History" are now dynamically allocated, rather >> than fixed-size arrays, so RECORD_LEN and MAXEDLINES no longer exist. >> >> Also, set/get functions are provided, eliminating the need >> to access the structure fields directly. >> >> Code which simply truncated strings to RECORD_LEN now stores the >> complete string. Code which breaks long strings into >> multiple lines has been preserved. > > as always, bloody excellent. > > > does anyone know/is involved with an OSGeo-wide library/project to deal > with the EU's INSPIRE metadata needs etc? (I'd really rather not attempt > to maintain our own fork of such a thing) > [e.g. something with GeoNetwork http://www.osgeo.org/geonetwork]
Thanks Hamish for the explanation and the reference to where in the code the limits are (were) kept. Thanks Glynn for the move to to dynamically allocated history fields. :-) In answer to the length of the filenames I was using... they were too long generally and I realised that I could avoid them. I was storing model outputs which included parameters, time step, model names etc to differentiate. Now I use separate mapsets for each specific combination of parameters and just use a subdirectory in the mapset for storing model metadata/analysis. edit: I just looked up some model logs where I was having the issue and the files causing the problems were 155 char long in a mapset 24 chars long. J _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev